* allow serviceData to override cacheSeconds with a longer value
* prevent [endpoint] json cacheSeconds property exceeding service default
* allow ShieldsRuntimeError to specify a cacheSeconds property
By default error responses use the cacheLength of
the service class throwing the error.
This allows error to tell the handling layer the maxAge
that should be set on the error badge response.
* add customExceptions param
This
1. allows us to specify custom properties to pass to the exception
constructor if we throw any of the standard got errors
e.g: `ETIMEDOUT`, `ECONNRESET`, etc
2. uses a custom `cacheSeconds` property (if set on the exception)
to set the response maxAge
* customExceptions --> systemErrors
* errorMessages --> httpErrors
* 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>
* Added Go version badge
* Using destructuring assignment
* Allowing a client to specify a filename
* Turned a test to live one
* Added golang to keywords
* Renamed parseContent to transform
* Added an example with branch and filename
I recently published https://github.com/metabolize/rq-dashboard-on-heroku and want to add badges to show the locked version of Python and rq-dashboard, the main dependency it’s wrapping.
This is along the lines of #2259, which was for package.json-based applications, and also included some discussion of a Python application that used `requirements.txt`. It’s useful for showing the pinned version of any dependency in a Python application that uses a lockfile.
In the future, as an alternative to reading Pipfile.lock, I could see expanding this to read Pipfile. However for my purposes I prefer to show the locked dependency, since that’s the version that a user of my package would actually get if they ran it on Heroku.
* 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
Continue to implement #2698:
- Add `core/base-service/index.js` (but hold off on moving the things it imports)
- Add shortcuts in `services/index.js` for Base*Service, errors, and deprecatedService. This file will be streamlined later to avoid cluttering it with rarely used bits.
- Apply consistent ordering of imports and use of `module.exports` in testers.
- Remove some renaming of imports.
- Remove obsolete tests here and there.
The GitHub service family is the largest, and as yet untouched by our service rewrite. I thought I would start the process by tackling one service.
This pull request has a few things going on:
1. Rename pull-request-status to pull-request-check-state. We have another badge called pull request status. It seems like the checks are called one thing in the UI and another thing in the API, which is unfortunate. If other folks have strong feelings about the name, I’ll defer.
2. Move its tests and tighten up the syntax.
3. Move its badge examples including the doc string.
4. Add a new helper `errorMessagesFor` to use in the new services in place of `githubCheckErrorResponse`. It seems like we didn’t really use the `errorMessages` parameter to `githubCheckErrorResponse`, so I pared this down. I’m not sure if this is the function we’ll ultimately want, but it seems like a good place to start.
5. Pull fetch code I _know_ we use in other places into `github-common-fetch`. As in the PR I just opened for azure-devops, this takes a functional approach to the shared code, which is more direct, nimble, and easy to reason about than inheritance.
6. Create `GithubAuthService` which functions identically to BaseJsonService, except for one thing, which is that it uses the token pool. I accomplished this by adding a `_requestFetcher` property to BaseService, which is initialized to `sendAndCacheRequest` in the constructor, and can be overridden in subclasses. Since we weren’t using `_sendAndCacheRequest` directly except in BaseService and tests, I removed that property. I like this approach to patching in the GitHub auth because it’s very simple and creates no new API exposure. However, the way we’re doing the dependency injection feels a bit odd. Maybe the eventual refactor of request-handler would be a godo time to revisit this.
The GitHub requests go through many, many layers of indirection at this point. Later on it would be good to shave some of these off, perhaps once the legacy GitHub services have been converted, or when all the services are done and we can take another look at the base service hierarchy. The work in #2021 and #1205 is also related.
