Based on some discussion/feedback here, this PR now contains several changes:
* Renames the `Sensiolabs` badge/service content to `SymfonyInsight` to reflect the rebranding of that product/service
* Refactors the original service to the new service model (using `BaseXmlService`)
* Updates the color scheme of the original/initial badge type (SymfonyInsight Grade) to more closely mirror the colors used by the vendor/service provider
* Adds a new badge type (violation counts/summary)
* Adds both mocked and live tests (there were none before) for both the grade & violation badges using the new path `symfony/i` as well as a couple tests for the old path `sensiolabs/i` to check for backwards compatibility
Refs #1358
This implements the configuration mechanism I described in #2621. The heavy lifting is delegated to [node-config](https://github.com/lorenwest/node-config) with a minor assist from [dotenv](https://github.com/motdotla/dotenv).
`private/secret.json` has been replaced with environment variables and/or `config/local.yml`. See `doc/server-secrets.md`.
* don't use a libraries.io token for bower integration
The libraries.io docs claim you need to be authenticated
to make any API request: https://libraries.io/api#authentication
In practice we can call https://libraries.io/api/bower/jquery
just fine with no token and based on chucking a load of
requests at it and examining the `x-ratelimit-remaining`
headers you actually seem to get a better limit with no
authentication.
All of our libraries.io badges in `services/librariesio`
seem to have been running fine with no token for some time.
* change jira auth settings to jira_user, jira_pass
All the other services use servicename_user, servicename_pass
This switches JIRA to use that convention by preference
but supports _username and _password for legacy users.
* add docs for server secrets
* add danger rule for server-secrets.md
this rule prompts users to update server-secrets.md
if 'serverSecrets' is in the diff
Fixes#2571 (Really fixed this time 😄)
I attempted a fix in https://github.com/badges/shields/pull/2590 using fake timers but didn't realize how the timestamps being used in `cache-headers` were being created. This approach uses a dynamically generated `if-modified-since` value that will now be 30 minutes ahead of the server time stamp used in the comparison.
Because `server.js` was long a monolith, there are a bunch of shims in place to facilitate unit testing. A few of the test suites share port 1111 which means if one of them fails to set up, the port won't be freed and other unrelated tests will fail. Some of the tests which trigger server setup include timeouts which were added to give setup code time to run. In one the test suites, we actually modify `process.argv`, which seems completely gross.
This implements a few changes which improve this:
1. Separate the server from the server startup script, splitting out `lib/server.js`.
2. Inject config into the server and validate the config schema.
3. Inject config into the service test runner.
4. Use `portfinder`, a popular utility for grabbing open ports during testing.
5. Switch more of the setup code from callbacks to async-await.
Overall it leaves everything acting more reliably and looking rather cleaner, if in a few places more verbose.
It also fixes the root cause of #1455, a `setTimeout` in `rate-limit`. Off and on during development of this changeset, Mocha would decide not to exit, and that turned out to be the culprit.
Fix#1455
Fixes#2524
This PR addresses the issues expressed in #2524, in that it:
* checks if a server has advertised a FQDN it can be reached at and if that FQDN hosts Matrix's client APIs
* uses room aliases instead of room IDs, in order to avoid a badge being impossible to generate if the server that created the room leaves it
This includes a breaking change to the badge endpoint.
Ports the Nexus service to the new service model. Some related/relevant conversation in #2347 (and closes#2347). Also adds support for authentication which resolves#1699.
Migrates the Jira badge services to the new service model, and also adds tests for those badges.
I did make one minor changes to the badge labels/messages when the issue or sprint cannot be found. For example:
With the LegacyService implementation, when an issue was not found the badge would display as 'issue key | inaccessible' such as `KAFKA-2869 | inaccessible` but this changes that behavior to `jira | issue not found`. I personally find this to be a bit more informative of a message, but want to call it out as I know how important backwards compatibility is. However, at first glance I'm also not sure how we'd replicate the old behavior of using the issue key (provided by user as a param) as the badge label when an issue is not found because the API response has a status code of 404 and a different schema than what Joi is expecting/validating.
Similarly for the sprints, the old format for a sprint not found was `completion | inaccessible` it's now `jira | sprint not found`
This adds a badge for collaborator count. When evaluating a library, it can be useful to know that there's not a single-contributor bottleneck for publishing. Having more than one collaborator is a sign of library maturity.
It adds another badge for dependency version of published dependencies, which solves a similar problem as the node-version badge. I will find this useful for making sure dependencies are up to date in a library.
