If Verdana.ttf can't be loaded, the font file pointed by the
FALLBACK_FONT_PATH environment variable will be loaded.
This fixes width computation errors that can occur with non-latin
characters when running with Docker.
- use `const` instead of `var` where possible
- use `'` instead of `"` consistently
- replace `forEach` loop with `reduce` call
Thanks to @Daniel15 for review!
* Add template for secret.json
- Move to faster and lighter Alpine base image
* Update documentation
* Update documentation
* Fix Github token config for secret.json
* Extend env file for Docker runtime configuration
- Update documentation
- Add gh_token for GH personal access token to secret template
* Change http to https in infoSite
* Update .dockerignore
* Update .gitignore
* Update dockerignore
* Remove ENV directive from Dockerfile
- Environment is needed at runtime, not at buildtime
* Docker: contain secret.json in private/
- Incorporates fix from 7c8b0e3d
* Use localhost in example env
* Use baseUrl in GitHub redirect
* Move GH personal token retrieval up
- To remove duplicate Promise.then()
* Typo in shields.example.env
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
