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
Please join me in welcoming @calebcartwright to the maintainer team!
Caleb has been doing an incredible job rewriting services, among other things, and we're glad to have him on board!
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.
The CSS in the project is relatively difficult to change. While it is very DRY, it relies heavily on inheritance. It's difficult to make changes in the markup modal without it also affecting styles elsewhere.
[styled-components](https://www.styled-components.com/) is one of the leading CSS-in-JS libraries. By reducing dependency on global state and CSS inheritance, styles become explicit and are easier to inspect and change. It's also convenient that styles can be embedded with the components they modify.
At runtime, the library creates CSS classes, so it's pretty efficient.
We were using a little bit of [styled-jsx](https://github.com/zeit/styled-jsx) before, which ships with Next.js, though styled-components is more widely used and I've had good experiences with it all around.
In a few cases I've duplicated styles where it feels more natural to do that: for example, `text-align: center` is duplicated in `Main` and `MarkupModal`.
Much of this is a refactor, though there are a few visual changes, particularly in the markup modal and the style examples.
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`
See https://circleci.com/docs/2.0/collect-test-data/
This provides a list of failed tests in the Circle UI and a summary of which tests have failed. It should make interpreting test results easier
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.
