Allow user to supply an arbitrary filter param to [GithubTag] and [GithubRelease] badges #9193
Conversation
| given({ tags, filter: 'server-*' }).expect(['server-2022-01-01']) | ||
| given({ tags, filter: '!server-*' }).expect(['v1.1.0', 'v1.2.0']) |
There was a problem hiding this comment.
I haven't really gone to town on testing different filters here. matcher has its own test suite.
I also haven't added any additional tests at the service layer. Just unit tests.
There was a problem hiding this comment.
I agree with the approach, we don't need to re-test the internals of a 3rd party library, just a couple of integration-like tests that give us confidence we're using that lib correctly.
Think you've fully cleared that threshold here 👍
| @@ -32,7 +32,7 @@ t.create('Release (No releases)') | |||
|
|
|||
| t.create('Prerelease (No releases)') | |||
| .get('/v/release/badges/daily-tests.json?include_prereleases') | |||
| .expectBadge({ label: 'release', message: 'no releases' }) | |||
| .expectBadge({ label: 'release', message: 'no releases found' }) | |||
There was a problem hiding this comment.
I've taken the opportunity here to align with the tag error message.
| sort: 'date', | ||
| isPrerelease: false, | ||
| }), | ||
| documentation: documentation + filterDocs, |
There was a problem hiding this comment.
The move to OpenAPI in #9014 and follow-on PRs is going to make it way easier to document services that have lots of optional query params and provide documentation relevant to individual parameters.
| if (!filter) { | ||
| return releases | ||
| } | ||
| if (displayName === 'tag') { |
There was a problem hiding this comment.
Here we apply the filter to either the release names or tag names depending on which is going to get displayed on the badge
|
👍 Dependency issues cleared. Learn more about Socket for GitHub ↗︎ This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored. |
|
The socket.dev issues are false positive. Turns out there are a lot of similarly named packages called lodash.something :) |
|
New dependencies detected. Learn more about Socket for GitHub ↗︎
|
This PR implements the solution discussed in #9173 and applies it to the GitHub Tag and GitHub Release badges, although we could apply the same approach to others in future.
We've talked through the reasons and use-cases for this, but this provides a fairly flexible solution which enables users to do things like
/github/v/tag/badges/shields?filter=%21server-%2Ain monorepos and other situations where repos contain a mix of different tags/releases.Closes #6253
Closes #6275
Closes #8205
Closes #9076
Closes #9080
Closes #9173
@calebcartwright - Although it would be nice to get this merged, if you've got time to review stuff, I am more keen to get #9014 over the line tbh.