* Add Keybase PGP badge
* Return 'not found' if the key is not present
* Change the default colour
* Add more constraints to the schema
* Render 64-bit fingerprints
* Add example
* Add a 'hex()' constraint to the fingerprint
* Improve error handling
* Add class 'KeybaseProfile'
* Add unit tests for Keybase PGP
* Add Keybase BTC
* Add unit tests for Keybase BTC
* Add Keybase ZEC
* Add unit tests for Keybase ZEC
* Add Keybase XLM
* Add unit tests for Keybase XLM
* Validate the BTC address using a regex
Regex taken from
https://mokagio.github.io/tech-journal/2014/11/21/regex-bitcoin.html.
* Exclude 'not found' from addresses' value in unit tests
* Remove useless keywords
* Add the link to the Keybase API documentation
* Move the colour into 'defaultBadgeData'
* Remove the HTTP method
'GET' is already the default one.
* Improve the error handling for Keybase BTC
* Add more constraints to the Keybase BTC schema
* Update one unit test for Keybase BTC
* Fix the error handling for Keybase BTC
* Add more unit tests for Keybase BTC
* Improve the error handling for Keybase ZEC
* Improve the error handling for Keybase PGP
* Improve the error handling for Keybase XLM
* Display a real username value in the examples
* Include the status code in the schemas
* Move the category to the base class
The same category is used by all badges.
* Add function 'transform' to the base class
The function 'transform' is used to encapsulate the error handling logic
as it is the same in each service.
1. Move tested server version to platform support, tweak description
2. Make version label consistent with others
3. Avoid setting category or defaultBadgeData in abstract base class
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.
As per #2913, this PR adds a new badge for the [HSTS preload][hsts] list.
Badges will use the format `/hsts/preload/:domain.svg` (e.g. `/hsts/preload/github.com.svg`)
Closes#2913
[hsts]: https://hstspreload.org
As described in #2340, this provides a way to replace an old alias with a redirect. This makes it easier to migrate our URLs over time without making our matching patterns more complicated.
The 301 redirect is sent back to the requester. If a user pastes the aliased URL into the address bar, it'll be replaced in the browser with the new URL, which gently encourages them to migrate.
Close#2340
This closes#2921 by switching ReSharper to the XML API used by Powershell, and refactors the powershell code back into the common nuget v2 service class. It also removes mocked tests of the color logic, replacing them with smaller-bracket tests that accomplish the same thing more concisely.
While Next.js can handle static sites, we've had a few issues with it, notably a performance hit at runtime and some bugginess around routing and SSR. Gatsby being fully intended for high-performance static sites makes it a great technical fit for the Shields frontend. The `createPages()` API should be a really nice way to add a page for each service family, for example.
This migrates the frontend from Next.js to Gatsby. Gatsby is a powerful tool, which has a bit of downside as there's a lot to dig through. Overall I found configuration easier than Next.js. There are a lot of plugins and for the most part they worked out of the box. The documentation is good.
Links are cleaner now: there is no #. This will break old links though perhaps we could add some redirection to help with that. The only one I’m really concerned about `/#/endpoint`. I’m not sure if folks are deep-linking to the category pages.
There are a lot of enhancements we could add, in order to speed up the site even more. In particular we could think about inlining the SVGs rather than making separate requests for each one.
While Gatsby recommends GraphQL, it's not required. To keep things simple and reduce the learning curve, I did not use it here.
Close#1943Fix#2837Fix#2616
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.
The suggest code was an exception to our usual organization pattern. There was a service test, but it's not a service. The code would sometimes regress because it wasn't being tested all the time.
This makes them no longer run as service tests, which is good because they run as part of every build. Some of them are smaller-bracket tests which is good too, because it will make them easier to test, especially as this code grows.
I'd have liked to keep using frisby for the ones that make requests to the server, though I ran into some issues with sequencing of setup that I think will require upstream changes.
The static previews don't support the social badges. Adding that lets us remove support for `exampleUrl`. Close#2479.
This includes `style` and `namedLogo` in the service-definition export and updates the frontend to use it. To accomplish this, it passes `namedLogo` through `coalesceBadge`. After logo resolution is moved to `makeBadge` this duplication can be removed, as `logo` will no longer be needed in the result of `coalesceBadge`.
The route helper functions are fairly well isolated from the rest of BaseService, with a few convenient entry points. They are easier to test in isolation.
The way the code was written before, `pathToRegexp` was invoked once for every request, which seems inefficient.
`route` was validated when it was used, though it seems more helpful to validate it up front.
This breaks out `_makeFullUrl`, `_regex`, `_regexFromPath` into new helper functions `makeFullUrl`, `assertValidRoute`, `prepareRoute`, and `namedParamsForMatch`.
It adds validation to route, and updates the services without patterns to include one, in order to pass the new validation rules.
Refs #2510
I'm going to delete or change some more logos in a further PR or two, but lets start off with the (hopefully) non-controversial ones. I think in all of these cases it is fairly clear-cut that we are not losing anything by removing our icon in favour of simple-icons now that we apply a sensible colour by default.
* feat: udpate vs marketplace download counts to handle azure devops scenario
* chore: added documentation info to download badge for AzureDevOps on VS Marketplace
* refactor: updated VS Marketplace Downloads badge to better cover Azure DevOps extensions
* feat: added separate service for ADO extension install badges
* refactor: simplifying vs marketplace statistics transform
* refactor: finished refactoring VS Marketplace services
* docs: added inline comment on VS Marketplace service base
* Tweak docs
* refactor: tweaked validation for VS Marketplace response
* chore: added todo in VS Marketplace base
* Tweak comment
* refactor: VS Marketplace base validation cleanup
* refactor: moved rating precision in VS Marketplace
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`.
