According to http://central.sonatype.org/pages/ossrh-guide.html#releasing-to-central:
> Upon release, your component will be published to Central: this typically occurs within 10 minutes, though updates to search can take up to two hours.
So, besides the delay, if the indexing jobs for search.maven.org are paused (see https://issues.sonatype.org/browse/OSSRH-27247), it may take quite some time to see the last artifact version even though it has been actually released on Maven Central.
This uses 'latest' version instead of 'release' version. According to the Maven documentation of the maven-metadata.xml (http://maven.apache.org/ref/3.2.5/maven-repository-metadata/repository-metadata.html):
- 'latest': what the latest version in the directory is, including snapshots;
- 'release': what the latest version in the directory is, of the releases only.
Using the 'release' version would imply altering the behavior of the badge, i.e. getting the release version instead of the latest version, which could also be a snapshot version.
Fixes#846.
According to the [Mozilla documentation about regular expressions](https://developer.mozilla.org/en/docs/Web/JavaScript/Guide/Regular_Expressions), the special character '\w' is equivalent to '[A-Za-z0-9_]', which does not include the hyphen character (i.e. '-'). This cause the matching of services containing a hyphen to fail (e.g. 'maven-central').
Reorg of the tests: move them just alongside their code. The principle relates to grouping by coupling, not by function and is established in best-practice documents (e.g. https://github.com/focusaurus/express_code_structure#underlying-principles-and-motivations), despite its break from the tradition of a separate `test/` tree. All of today's tools can handle tests spread through the repository.
There are some good, if subtle consequences of this change:
- Since files are close at hand, friction is reduced at development time, which encourages that new tests are written to cover new behaviors.
- It's easier to find the tests that cover a particular piece of functionality.
- It's easier to see which code has tests and which doesn't.
- Eliminate manual testing which is error-prone and time consuming, and must be repeated many times through the PR review process
- Make contributing more fun. For many, fixing bugs and making new badges is faster and more satisfying with automated tests than with manual testing.
- Push out the work of testing new badges to a much broader net. The PR originator could write tests, but so could any other contributor who wants to push review along.
- Detect badge failures resulting from changes in vendor contracts without waiting for user reports.
- Detect and prevent regressions in the code.
- Be runnable, readable, writable, and editable by as many developers as possible, including those who may not be familiar with JavaScript test tools.
-- @paulmelnikow, @niccokunzmann, @Daniel15
The website relies on GitHub Pages. When created, that did not support
TLS. However, last year, support for TLS was added, as detailed
in the following blog post:
https://github.com/blog/2186-https-for-github-pages
- Build index.html at deploy time
- Update corresponding documentation references
- Since index.html is untracked, git add needs -f
- Clarify gh-pages generated commit message
- Improve Makefile dependencies related to website generation
As discussed in #936, tracking the index.html causes makes PRs longer / noisier
and causes extra merge conflicts. More importantly, it causes contributors to
inadvertently edit the wrong file, which causes extra work (#949) or
contributions to be lost (#898).
Since there's no need for index.html in development (everything uses try.html) a
logical solution is to generate and commit the index.html at deploy time.
Recording compiled or generated files in a deploy commit is a reasonable
practice for git-based deploys (Heroku, gh-pages, and others).
The old version of this was slightly "unsafe" for my taste, in that it depended
on the local copy of gh-pages (if it existed) and master. The new version just
replaces gh-pages with master + the new commit.
Closes#936.
Fixes#954 (the PR).
While working on some tests, I was having a tricky problem in a test suite. Eventually I tracked it down to an interaction between tests. I suspected the test library, but once I tried to make an isolated test case, I realized the test library was working fine. It turns out it was the server’s request cache. The fix is to clear the cache between tests.
Not needed for this PR, though I’m adding it to this branch because it conflicts with this change.
Running the server in process is necessary for the mock to work. This is an approach I’ve taken in the past. I experimented with this setup quite a bit when I was playing around with a test suite, and it seemed to work well enough. Setting `process.argv` is a admitedly a bit gross, though a cleaner approach would require more involved changes to `server.js`.
Given the chunks coming from imagemagick are getting stored memory and
then tucked into a cache, this function could as easily return a buffer
via callback. Streaming is just making it more complex. (And trickier to
test!)
In ef1a5159, the switch to using imagemagick made a faulty use of the library by
listening for an 'end' event that is never raised. As a result, the cache was
never populated.
In d985f81f, a fix that takes care of the fact that the previously mentioned
dead code relies on a non-existent variable caused it to kill the server when a
raster badge is requested twice, as what it stored in the cache was the pipe
transmitting chunks, not the chunks themselves, and the pipe (a Socket object)
cannot be subsequently sent through a pipe. The following error occured instead:
events.js:163
throw er; // Unhandled 'error' event
^
TypeError: Invalid non-string/buffer chunk
at chunkInvalid (_stream_readable.js:395:10)
at readableAddChunk (_stream_readable.js:150:12)
at DataStream.Readable.push (_stream_readable.js:136:10)
at DataStream._read (/home/m/shields/lib/svg-to-img.js:45:21)
at DataStream.Readable.read (_stream_readable.js:350:10)
at resume_ (_stream_readable.js:739:12)
at _combinedTickCallback (internal/process/next_tick.js:80:11)
at process._tickDomainCallback (internal/process/next_tick.js:128:9)
