* feat: add forcePrerelease option to renderVersionBadge function
Sometimes API would indicate if a version is pre-release while the version number does not have to be semantically a prerelease like in github-release service.
We don't use a isPrerelease that can also force a non-preleases as we trust here developer semantic over API tagging.
* refactor: GithubRelease to use renderVersionBadge
* refactor: GithubTag use renderVersionBadge
* refactor: change forcePrerelease to isPrerelease
* fix github service tests
* migrate some services from examples to openApi
* document latest variant with separate examples
making seperate routes for the /{version} and /latest variants
allows us to only show the docs for
- include_prereleases
- sort and
- filter
in the situation where they are relevant
* feat: support using release or tag name in GitHubRelease version badge
* add comment to query param test
Co-authored-by: repo-ranger[bot] <39074581+repo-ranger[bot]@users.noreply.github.com>
* move getLatestRelease logic from [GitHubRelease] to common-fetch
- so that the sorting and prerelease logic can be used for other
services too, like commits-since
* add sort and prerelease query params to [GitHubCommitsSince]
- they only work when using the 'latest' version of course
- uses same logic as release service
* reuse queryParamSchema from common-fetch for [GitHubTag]
- as they were the exact same schema
* refactor [GitHubCommitsSince] tests to use withRegex
- and the same variable everywhere
* split out release/tag logic from common-fetch to common-release (affects [GitHubCommitsSince], [GitHubRelease], [GitHubTag])
- this logic is only used for code related to releases & tags, so made
sense as a split point
Co-authored-by: Caleb Cartwright <calebcartwright@users.noreply.github.com>
* move GH tag and release under /v, move variants to query params
- move github /tag and /release under /v
- both sort by date as default
- specify sort=date/semver, include_prereleases as query params
- use graphql api for tags
* pass string params from example defs to modal
* add base class for Graphql APIs
* add GithubAuthV4Service + updates to GH token pool
* update github forks to use GithubAuthV4Service
* rename GithubAuthService to GithubAuthV3Service
* which --> variant
* which --> alias
* which --> format
* improve param names in codeclimate
* improve param names in github-issue-detail
* update github-issue-detail unit tests
This moves a few helpers from `lib/` to `services/`:
build-status.js
build-status.spec.js
color-formatters.js
color-formatters.spec.js
contributor-count.js
licenses.js
licenses.spec.js
php-version.js
php-version.spec.js
text-formatters.js
text-formatters.spec.js
version.js
version.spec.js
And one from `lib/` to `core/`:
unhandled-rejection.spec.js
The diff is long, but the changes are straightforward.
Ref #2832
This is consistent with what we're pretty much already doing, and saves us from making the request during code review.
These were all autofixed and most of them seem easier to read. Some in the legacy services should be rewritten in more legible forms during refactor (ie using intermediate variables, or using request’s qs option). There are some in helper functions and elsewhere that should get rewritten separately. I don't want to change them in this PR because the changes will get lost in this diff, though we could identify them here and fix them before or just after.
