The TokenProvider abstraction was refactored away during #1205 and is now obsolete. Other users of token pooling should use TokenPool and TokenPersistence directly.
This reimplements the idea @bkdotcom came up with in #1519, and took a stab at in #1525. It’s a really powerful way to add all sorts of custom badges, particularly considering [tools like RunKit endpoints and Jupyter Kernel Gateway](https://github.com/badges/shields/issues/2259#issuecomment-444186589), not to mention all the other ways cloud functions can be deployed these days.
In #2698 we decided to put legacy helper functions in `core/legacy`. I think that’s a fine idea, though if we’re going to have a bunch of badge helper functions in there, it seems like it is probably better to keep these two important but esoteric helper functions with the core code to which they are most coupled. So I added `legacy-` to the name, and put them in `core/base-service`.
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.
We had only a few function expressions declared with the function keyword; almost everything is using function declarations.
This came up after this discussion: https://github.com/badges/shields/pull/2803#discussion_r249011621 though is actually not related ot that example.
What’s being removed is a third option, which is assigning to a variable a function expression using the `function` keyword. There’s still room for the programmer to choose between arrow function expressions and function declarations.
It still seems worth using workspace caching to properly tackle #1937, though in the meantime we're wasting time with a useless build. This should cut our total build latency roughly by half.
This test is being weirdly flaky in #2809. The problem seems to be in the test helper code, so I rewrote this using Joi.
I imagine the change has to do with a change to the test ordering. It's a bit puzzling.
However, the new test seems fine (and the endpoint is rarely used; not critical to begin with).
This renames `npm run test:server` to `npm run test:core` to go along with the reorganization of #2698. `server` has been a bit imprecise, since there's a lot of stuff under test besides the server, and most of the tests don't hit the server itself.
Probably files like `luarocks.spec.js` ought to be run as part of a different target, especially if we build out a separate code-coverage metric for core. Though I'm not in a huge rush to sort that out.
The intention of wrapping HTML in an `__html` is to avoid accidentally unsafe rendering of something that is non-html.
Including this in the definition export solves the problem, and does not seem too onerous for other possible users of that file.
Close#2725
* fix: updated Azure DevOps fetch function to reflect query param name change
* fix: fixed branch filter for azure devops to enable branch name usage
* fix: simplified branch pattern for azure devops badges
It’s happened twice that `[*]` has ended up in a PR title and the full test run has happened inadvertently. Once was me and once was a new contributor.
This raises the bar on doing it accidentally.
Numeric colors weren't properly being handled by `makeBadge` after #2742.
Since this function really does not need to be accepting colors as strings, rather than make the function more lenient to work with Scoutcamp, I coerced the types of the colors on the way in.
Two tests cover the functionality in the modern service. I don't feel strongly that the legacy version needs coverage at this point, though I've added one for the moment on the github languages badge where this manifested.
Fix#2778
