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.
- The goal of this PR is:
- Consume the new service-definition format. (#2397)
- Make the frontend more readable.
- Behavior changes:
- I changed the **Image** field in the markup modal to show only the path.
- I added another click-to-select field below that shows the complete URL.
- This made it easier to suppress the live badge preview while it contains placeholders like `:user` or `:gem`, a minor tweak discussed at https://github.com/badges/shields/issues/2427#issuecomment-442972100.
- The search box now searches all categories, regardless of the current page. (This is an improvement, I would say.)
- I did not deliberately address performance, though I ripped out a bunch of anonymous functions and avoided re-filtering all the examples by category on every render, which I expect will not hurt. I haven't really tested this on a mobile connection and it'd be worth doing that.
- It would be great to have some tests of the components, though getting started with that seemed like a big project and I did not want to make this any larger than it already is.
It's a medium-sized refactor:
1. Replace `BadgeExamples`, `Category` and `Badge` component with a completely rewritten `BadgeExamples` component which renders a table of badges, and `CategoryHeading` and `CategoryHeadings` components.
2. Refactor `ExamplesPage` and `SearchResults` components into a new `Main` component.
3. Rewrite the data flow for `MarkupModal`. Rather than rely on unmounting and remounting the component to copy the badge URL into state, employ the `getDerivedStateFromProps` lifecycle method.
4. Remove `prepareExamples` and `all-badge-examples`.
5. Rewrite the `$suggest` schema to harmonize with the service definition format. It's not backward-compatible which means at deploy time there probably will be 10–20 minutes of downtime on that feature, between the first server deploy and the final gh-pages deploy. 🤷♂️ (We could leave the old version in place if it seems worth it.)
6. Added two new functions in `make-badge-url` with tests. I removed _most_ of the uses of the old functions, but there are some in parts of the frontend I didn't touch like the static and dynamic badge generators, and again I didn't want to make this any larger than it already is.
7. Fix a couple bugs in the service-definition export.
This starts the rewrite of the dynamic badges. I've pulled into BaseService an initial version of the query param validation from #2325.
I've extended from BaseJsonService to avoid duplicating the deserialization logic, though it means there is a bit of duplicated code among the three dynamic services. The way to unravel this would be to move the logic from `_requestJson` and friends from the base classes into functions so DynamicJson can inherit from BaseDynamic. Would that be worth it?
This introduces a regression of #1446 for this badge.
Close#2345
* Added matrix badge
* decreased the size of the matrix logo by more than 50%
* returning the size in fetch() instead of an object
* found another way to register a throwaway account (guest account). this one actually works on matrix.org, but I kept the old way as a backup method. also changed the POST from /members to /state because guest accounts didn't work with /members
* updated logo to a recolored version of the official logo
* Removed unnecessary comments.
Added documentation on how to create the badge URL.
Added a test that hits a real room to test for API compliance.
URLs are now obtained from getter functions.
Added JSON schema for the /state API request.
Improved state response filter.
Replaced example URL room ID to a dedicated testing room.
Made some error messages more helpful.
* correctly implemented requested changes
* changed color hex codes to constants
Now that we have [PowerShell Core](https://github.com/powershell/powershell) the cross-plat version of PowerShell... it'd be really cool to have a badge that shows the OS's that your module works on.
On the PowerShell Gallery, users can do this by using the tags `Windows` `MacOS` `Linux`. In this PR, I use the PowerShell Gallery API to grab the tags from that package and display `windows` `macos` `linux` if they exist.
The result is:

which aligns with Conda and Cocoapods
* Correct regex generation logic
* Refactor variable name
* Mock Azure DevOps test result summary API
* Add live tests
Updated mocked tests to use expected values for assertion. Added live
tests to test the API. Added `no tests` as an acceptable result for live
tests.
* Declare common nock setup functions to avoid repetition