* set followRedirect: false by default in tests
* update tests implicitly relying on redirects
Co-authored-by: repo-ranger[bot] <39074581+repo-ranger[bot]@users.noreply.github.com>
* Convert remaining tests to use expectRedirect() helper
* convert last few redirect tests to use svg not json
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
* 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
This pull request closes#2551: making sure that the keywords don't already appear in the example's title.
I also added validation that checks that they are at least two characters long, as this is enforced by the homepage when type your search.
Fixes#2876 with @paulmelnikow's suggestion
Moved imports of `ServiceTester` and `createServiceTester` to a separate file so that dev dependencies are not imported by service classes.
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.
- Replace the idea of color schemes with the idea of named colors (since none of our colorschemes have used `colorA`)
- Pass through the normalized color to `_shields_test` to harmonize with BaseService and simplify testing
- Update service tests
- Move responsibility for color generation into the npm package
- Remove several color helper functions and their tests
- Update gh-badge public API to accept `color` and `labelColor`
This is a precursor to refactoring some of the logo code for #2473.
This implements the configuration mechanism I described in #2621. The heavy lifting is delegated to [node-config](https://github.com/lorenwest/node-config) with a minor assist from [dotenv](https://github.com/motdotla/dotenv).
`private/secret.json` has been replaced with environment variables and/or `config/local.yml`. See `doc/server-secrets.md`.
* don't use a libraries.io token for bower integration
The libraries.io docs claim you need to be authenticated
to make any API request: https://libraries.io/api#authentication
In practice we can call https://libraries.io/api/bower/jquery
just fine with no token and based on chucking a load of
requests at it and examining the `x-ratelimit-remaining`
headers you actually seem to get a better limit with no
authentication.
All of our libraries.io badges in `services/librariesio`
seem to have been running fine with no token for some time.
* change jira auth settings to jira_user, jira_pass
All the other services use servicename_user, servicename_pass
This switches JIRA to use that convention by preference
but supports _username and _password for legacy users.
* add docs for server secrets
* add danger rule for server-secrets.md
this rule prompts users to update server-secrets.md
if 'serverSecrets' is in the diff
Migrates the Jira badge services to the new service model, and also adds tests for those badges.
I did make one minor changes to the badge labels/messages when the issue or sprint cannot be found. For example:
With the LegacyService implementation, when an issue was not found the badge would display as 'issue key | inaccessible' such as `KAFKA-2869 | inaccessible` but this changes that behavior to `jira | issue not found`. I personally find this to be a bit more informative of a message, but want to call it out as I know how important backwards compatibility is. However, at first glance I'm also not sure how we'd replicate the old behavior of using the issue key (provided by user as a param) as the badge label when an issue is not found because the API response has a status code of 404 and a different schema than what Joi is expecting/validating.
Similarly for the sprints, the old format for a sprint not found was `completion | inaccessible` it's now `jira | sprint not found`
The term “url” is overloaded in services, to refer to the Shields route and also the API URL. Calling the Shields URL a “route” is on the whole more descriptive, and makes it clearer and more obvious which one of these we’re talking about. It’s a small thing, though seems like an improvement.
We have a few functions called `buildUrl`. I’ve renamed them to `buildRoute` when they refer to routes, and left them as `buildUrl` when they refer to API URLs.
I included a minor style tweak and some formatting cleanup in `TUTORIAL.md`.
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.
all-badge-examples is a common cause of merge conflicts. It’s difficult to adjust the badge categorization in that file – or to understand the diff – because it requires moving a block from one point to another. It’s much easier to edit a badge’s category in one place.
This starts the process of breaking up what’s left of that file, following up on the work from #1931. New-style services can only be in one category, which means legacy service examples have to be split along category lines. I split out separate legacy service classes where I could do so easily, leaving behind the ones which require more work, for one reason or another.
