* 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
* Converted [swagger] from static class to props
* Converted [symfony teamcity travis treeware] from static classes to props
* Fixed staticPreview field in travis
Co-authored-by: Jabbar Memon <jabbar@zoop.one>
Co-authored-by: repo-ranger[bot] <39074581+repo-ranger[bot]@users.noreply.github.com>
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()`
* feat: added stars badge for symfony insight
* refactor: changed symfony star determination logic
* feat: updating symfony to handle old scan scenarios
* feat: updated symfony insight to handle older projects
* tests: removed another test for symfony insight per request
