* Response size metric for all services
* Unused code removed
* Test for service response size metric
* All buckes of the service_response_bytes in a comment
* Register parameter in PrometheusMetrics is optional
* service response size metric enabled for dynamic badges
* Better test name
* JSDoc removed
* One import from one file
* Gather metrics in the background
* Revert saving response time metrics in the background
* Subclass factory for JSON path services
* Common methods moved to JSON path class
* should throw error if _getData is not overridden
* Test JSON path factory using chai-as-promised
* Using chai-as-promised in more tests
* JSDoc for json-path
* Error message adopted to JSON and YAML
* Dynamic YAML badge handles YAML with a string
* 'fetch' naming covention
* Strict string validation in error message
* Refactor existing metrics support into MetricHelper
This completes the refactor done at https://github.com/badges/shields/pull/3662#issuecomment-509011229 in anticipation of adding more metrics support, such as response size of an upstream service, or response time.
* Clean up
* Renames
* Add response time metrics
This adds around 30 new metrics to cover response times at a fairly granular level. We may be able to shrink the number of buckets with time, though I think using 30 metrics is probably okay given that I think may become our most important metric.
* Fix
* add base class for Graphql APIs
* add GithubAuthV4Service + updates to GH token pool
* update github forks to use GithubAuthV4Service
* rename GithubAuthService to GithubAuthV3Service
Use of this feature [has been discouraged for a long time](https://nodejs.org/api/domain.html).
Since most of our code is now bubbling through async, we aren't really getting these "vendor errors" anymore.
Errors that _do_ bubble up through the services have been reported to Sentry since #3706, though they seem to be missing a bunch of their stack traces. Sentry also seems to be combining unrelated internal errors. (https://github.com/badges/shields/issues/3709#issuecomment-514299441) Maybe this will help.
Adding TypeScript to the frontend and a `.d.ts` file to `core` (see #3742) has multiplied out the different combinations of lint rules. ESLint has support for file-pattern-based overrides, which we've used in some places, but we've also maintained a separate eslintrc for `frontend/`.
This merges the config together, with the strategy of putting all the rules at the top level except where they conflict, and applying settings to exactly the files where they should apply.
This introduces a few new errors in the server but they are true positives – hoisting and lowercase class names – things we don't really need to be doing).
This is a reworking of #3410 based on some feedback @calebcartwright left on that PR.
The goals of injecting the secrets are threefold:
1. Simplify testing
2. Be consistent with all of the other config (which is injected)
3. Encapsulate the sensitive auth-related code in one place so it can be studied and tested thoroughly
- Rather than add more code to BaseService to handle authorization logic, it delegates that to an AuthHelper class.
- When the server starts, it fetches the credentials from `config` and injects them into `BaseService.register()` which passes them to `invoke()`.
- In `invoke()` the service's auth configuration is checked (`static get auth()`, much like `static get route()`).
- If the auth config is present, an AuthHelper instance is created and attached to the new instance.
- Then within the service, the password, basic auth config, or bearer authentication can be accessed via e.g. `this.authHelper.basicAuth` and passed to `this._requestJson()` and friends.
- Everything is being done very explicitly, so it should be very clear where and how the configured secrets are being used.
- Testing different configurations of services can now be done by injecting the config into `invoke()` in `.spec` files instead of mocking global state in the service tests as was done before. See the new Jira spec files for a good example of this.
Ref #3393
I find having these in a consistent order makes the services much faster to read.
This is the order I’ve generally been using:
1. Category
2. Route
3. Examples
4. Rendering
5. Other helpers (`fetch()`, `transform()`)
6. `handle()`
Attacking this in two pieces for ease of review. The legacy implementation for coverage is still there, though I disabled it via the route. That whole file will be removed in the next PR.
Ref #2863
* Modernised JSON format and removed _shields_test style
* Added logoWidth and labelColor fields to JSON response
* Reinstated and updated comment
* Extended expectBadge to accept Joi schemas for all fields
* Label all deprecated services as such
This will change
service_requests_total{category="other",family="cocoapods",service="cocoapods_apps"} 76
to
service_requests_total{category="other",family="cocoapods",service="deprecated_cocoapods_apps"} 76
* Fix tests
