The intended behavior of the bracketed [github], [bower], [discord] service names in the pull request title is to trigger the designated service tests. That way, affected services can be proven working during code review, without needing to run tests on a dev machine, nor running all the slow (and flaky) service tests.
Example pull request titles:
- [Travis] Fix timeout issues
- [Travis Sonar] Support user token authentication
- [CRAN CPAN CTAN] Add test coverage
The observed behavior is that, whenever bracketed service names are provided, all of the service tests run.
This is due to a Mocha limitation, which is that exclusive tests (it.only and describe.only) can only be applied synchronously. In other words, if we try to fetch the PR title and then add exclusive tests in the callback, all the tests will run anyway. This is true even when using _mocha --delay, as we are, and is true whether I use request or node-fetch.
Undoubtedly this could be fixed, though it's not worth it. The problem is obscure and therefore low priority for Mocha, which is quite backlogged.
And, there is an easy workaround, which is to generate the list of services to test in a separate process.
The pull request script test:services:pr is now split into two parts. First the :prepare script infers the pull request context, fetches the PR title, and writes the list of affected services to a file. Then the :run script reads the list of affected services and runs the appropriate tests.
In addition to sidestepping the Mocha bug, this setup makes it easier to reason about and debug these two steps of the test runner on a dev machine, and since I can't get pipefail to work – and want to be able to run the steps separately – I'm not using Node's built in pre scripts.
Overall, separating these concerns this makes the test runner easier to reason about.
- Except for social badges, omit logos by default (#983)
- Omit the logo from a social badge using the query string: `?logo=`
(#983)
- Opt in to named logos using the query string: `?logo=appveyor`
- Provide custom logo data as before: `?logo=data:image/png;base64,...`
- Rewrite badge data functions, with unit tests
Unit tests are covering the new code very well, though the underlying
functionality (logos) is untested.
Close#983
- Update 'downloads'->'users' as label,
- added `/u/` as option
- kept `/d/` as an option for backwards compatibility
- moved example from 'Downloads'->'Misc' section
Closes#1016
The original code has been simplified as well, but commented out.
I don't think we need the original code using the issues API, as it has
some limitations (no label support, only up to 30, or 100 issues).
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.
