The example we were previously using
(Az.Storage) now renders
platform | not specified
This replaces the example with a
package that gives us a valid result
* Show patterns instead of real paths
* realBadge property instead of preview.buildFromExample
* E2e test for displaying a badge
* Check bagde url in badge wrapper
* expectBadgeExample helper function
* Remove a hostname from badge url
* Simpler Cypress assertions
* realBadge -> isBadgeSuggestion
* Do not show regexp in patterns
* which --> variant
* which --> alias
* which --> format
* improve param names in codeclimate
* improve param names in github-issue-detail
* update github-issue-detail unit tests
* Add subreddit subscribers service file.
* Fix small detail in service and add the tests files.
* Apply suggested changes by the reviewer.
* Trying to make tests work.
* Update services/reddit/subreddit-subscribers.tester.js
Co-Authored-By: Caleb Cartwright <calebcartwright@users.noreply.github.com>
* Update services/reddit/subreddit-subscribers.tester.js
Co-Authored-By: Caleb Cartwright <calebcartwright@users.noreply.github.com>
* Apply suggested changes.
* Add different handler for non existing and invalid subreddits.
* Update services/reddit/subreddit-subscribers.service.js
Co-Authored-By: Caleb Cartwright <calebcartwright@users.noreply.github.com>
* Improve tutorial file with explaining how to solve an error.
* Fix typo.
* Fix typo.
* Add more information about the fix.
* Apply suggested changes.
* Add missing method in the first example
* Modify the second example that did't compile.
* Add troubleshooting for the localhost and link to the issue solving it.
* Rephrase.
* Update doc/TUTORIAL.md
Co-Authored-By: Caleb Cartwright <calebcartwright@users.noreply.github.com>
* Add get category() function explanation in both examples.
* Update doc/TUTORIAL.md
Co-Authored-By: Paul Melnikow <github@paulmelnikow.com>
* switch [circleci] service to scrape SVG badge
* reorganise [circleci] routes
Default URL is now
circleci/build/gh/badges/shields/master?token=abc123
There are redirects on the legacy routes to provide
backwards compatibility for existing users
Fixes https://github.com/badges/shields/issues/3260
Problem happens when a value of a color in an old PNG static badge is a number: http://localhost:8080/my-label/my-message.png?color=1. In this case `color` in `queryParams` is a number.
0a0b5b3f03/core/server/server.js (L203-L212)
Surprisingly service test listed below is passing currently on master - value `1` is represented in `queryParams` as a String (only in test).
`services/static-badge/static-badge.tester.js`
```js
t.create('Old static badge with a number as a color')
.get('/foo/bar.png?color=1', { followRedirect: false })
.expectStatus(301)
.expectHeader('Location', '/badge/foo-bar-1.png')
```
Moreover I added some code + description allowing to debug server.
* Fix LGTM badges for non-GitHub projects.
* Allow using full repository host names in LGTM badge URLs.
* Add an LGTM redirector service to redirect old LGTM badge URLs to new LGTM badge URLs.
* Add LGTM redirector tester.
* Remove unneeded check in LGTM base file.
Co-Authored-By: chrisgavin <chris@chrisgavin.me>
While working on #2428 I found myself wanting to reload the server frequently. This is working great and reducing my iteration time significantly. I should have tackled this way sooner! 🙊
I’ve left `verbose` on which seems useful, at least in the short term while we’re tuning the configuration.
Close#2426
* Add [Ubuntu] package version support
https://api.launchpad.net/1.0/
* Mark 400 responses as series not found
* Extract API call into separate fetch function
* Display suggested badges
* E2e test for badge suggestion
* Suggest resource returns example with pattern
* Do not require preview in MarkupModalContent
* Skip integration test for suggestion
* Unmodifiable path in customizer
* Use suggested link
* Allow to change suggested badges
* Enable skipped test
* Enable skipped test
* Code refactoring
* Code refactoring
* Code refactoring
* Code refactoring
* Code refactoring
* Code refactoring
* Unused code removed
* Unused code removed
* getExampleWithServiceByPattern helper added
* BadgeExamples uses examples instead of services definitions
* Revert "getExampleWithServiceByPattern helper added"
This reverts commit 80839fd705.
* style removed from example
* example.exact replaced with preview.buildFromExample
* keywords are required again
* Code refactoring
* More e2e tests for suggestion feature
* Code refactoring
* Build add with a base url
* showActualParams -> isPrefilled
* A new schema for BadgeExamples
* Link moved to queryParams
* Updated documentation for the suggest reponse format
* Link moved to queryParams - another test updated
* Revert "Link moved to queryParams - another test updated"
This reverts commit b5f811bb07.
* Revert "Link moved to queryParams"
This reverts commit 3b54c6d2b4.
* Disable changes in path in suggested badges
* 'link' element documentation restored
* refactor(Scrutinizer): migrated to new BaseJsonService
* refactor(ScrutinizerCoverage): updated color scale to match
* refactor(Scrutinizer): switched to multiple classes to handle dif. git hosts
* refactor(Scrutinizer): finished migrating to new service arch.
* fix(Scrutinizer): fixed branch check logic
* refactor(Scrutinizer): inline transforms based on PR feedback
* refactor(ScrutinizerCoverage): change handling of no coverage scenario
* refactor maven central
* misc fixes
- include a pretty message on NotFound when the filter returns no results
- split the group and artifact into seperate variables
- remove the connection error test
* remove xml parsing test and add inexistent version prefix test
* use existing test validators and shorthand createservicetester
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()`
* refactor(JenkinsTests): finished core refactor to new service model
* refactor(JenkinsTests): more updates
* refactor(JenkinsCoverage): minor refactor to leverage new common Jenkins content
* refactor(JenkinsBuild): update redirector to include shorthand alias
* chore: apply suggestion on jenkins-tests.service.js
Co-Authored-By: calebcartwright <calebcartwright@users.noreply.github.com>
* refactor(JenkinsTests): rename test helpers
* chore: cleanup JenkinsCoverage redirector
* chore: cleanup JenkinsBuild redirector
* chore: cleanup test docs
* [Bit] add bit components count service
* [Bit] change 404 error to 'collection not found'
* [Bit] remove comment
* [Bit] change collection schema
* [Bit] use isMetric
* [Bit] replace static color to dynamic color
* [BIt] change bit total components route
* change scope to collection
* change all scope var to collection
- Prefer inline transforms to take place in `handle()` rather than `render()`
- Avoid inversion of control by removing `BaseWordpress#handle()`, passing `extensionType` into `fetch()`, and removing one layer of subclassing
- Move “not found” checks into `fetch()`
- Cache wordpress versions instead of fetching on each request
- Start to convert aliases to redirects (there are more of these which could be tackled in a follow-on)
- Replace at least one route `format` with a `pattern` (ref #3329)
- Partially reorder: name, category, route, examples, defaultBadgeData, render, fetch, handle
Some of this is in line with our established patterns or makes it clearly easier to follow; some of it is arguably stylistic.
* Use url `pattern` for [nexus]
* chore: minor nexus example tweaks
* chore: fix prettier issue
* refactor(Nexus): minor refactor to fix tests and examples
* chore: increase timeout on nexus service tests
* chore: prettified for prettier
* tests(Nexus): increase timeout for recurringly slow test
* chore: update nexus schema with docs
* refactor(JenkinsBuild): ported to new service model
* refactor(JenkinsBuild): added redirector for jenkins-ci route
* refactor(JenkinsBuild): trying to debug test on circle
* refactor(JenkinsBuild): fix test of mock creds
* chore: fix typo in wrong file 🤦
* refactor(JenkinsBuild): update route
* refactor(JenkinsBuild): fixed service test
* refactor(JenkinsBuild): made strictSSL configurable via QP
This moves the four npm download services into a single class, in line with #3174, and other service implementations we've written in the last couple months.
1. Change the suffixes from **/m** to **/month** for consistency.
2. Add tests of one of the intervals besides total.
3. Rewrite mocked service tests as unit tests.
4. Use (and work with) the `intervalMap` pattern that I think @calebcartwright started us using.
* Add drone build badge based on travis
* Fix wrong mocked endpoint for done builder
* Refactor service tester using helper method
* Add missing failure status to red statuses
* Remove extraneous invalid svg test from drone
* Test on failure red status in build status spec
* refactor(drone): use json service instead of svg
* refactor(drone): remove status text and extraneous build path in test
* refactor(drone): allow defining self-hosted drone instances
* fix(drone): use proper urls in drone examples
* fix(drone): add drone token authorization for self-hosted instances
* refactor(drone): call render build status badge directly instead of render
* refactor(drone): use server query parameter for self-hosted instances
* fix(drone): separate url and query params in example
* fix(drone): use actual build status message in examples
* fix(drone): add missing message for status code 401
Co-Authored-By: byCedric <me@bycedric.com>
* refactor(drone): remove color from drone tests
* refactor(drone): remove extraneous comments from drone tests
* refactor(drone): remove unused static preview method
* refactor(drone): remove unused static render method
* refactor(drone): reuse render build status badge helper in static previews
* fix(drone): test inaccessible repos on new message
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
* refactor(sonar)
* refactor(sonarqube): creating separate services for SQ badges
* refactor(sonar): more sonar refactorings
* refactor(sonar): fixed duplicate service names from c/p
* refactor(sonar): finished violations service impl
* refactor(sonar): finished unit tests for violations service
* feat(sonar): violation badge updates
* refactor(sonar): finished doc. api density service
* feat(sonar): added quality gate service
* chore: sonar doc tweaks
* refactor(sonar): added redirector service
* refactor(sonar): added examples
* refactor(sonar): minor example updates
* refactor(sonar): added final tests
* chore(sonar): removed unneeded test spec file for base class
* refactor(sonar): updates based on PR feedback
* refactor(sonar): change query param to sonarVersion
* refactor(sonar): fixing query param issue
* refactor(sonar): fix test color for generic metric
* chore: fix lint/prettier issue
* chore(sonar): update query param name in examples
* refactor(sonar): make schema metric key required
* reactor(sonar): fix tests
* refactor(sonar): added more example listings
* refactor(sonar): minor style updates
* refactor(sonar): update examples
* refactor(Sonar): minor example tweaks
Not really sure what happened, but the test for the deprecated gratipay/gittp service has been failing for a while with a 404 badge not found error. For example
`AssertionError: label mismatch: expected '404' to equal 'gratipay'`
This tweaks the rout pattern so the test is passing again.
One of the tests for the Maintenance service that was added when the service was refactored is failing
`AssertionError: message mismatch: expected 'no! (as of 2018)' to equal 'stale (as of 2019)'`
I believe the test was added in an attempt to cover the one of the code paths, but that original test would only pass a couple months out of the year.
Testing those paths with the original implementation would have required a lot of stubbing clocks/timers, so instead I refactored the code a bit. I removed the flaky live/service test, and added some unit tests instead (which made more sense to me since this service badge doesn't hit a live endpoint)
This migrates the puppetforge-modules from legacy
services to the new service arch
There are also some changes to the puppetforge-users
badges, but its just moving code around
* 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
* refactor(GithubIssueDetail): ported to new service model
* refactor(GithubIssueDetail): updates based on PR discussions
* refactor(GithubIssueDetail): minor updates and additional tests
* refactor(GithubIssueDetail): minor updates to render functions per PR disc.
* Frontend test using Cypress
* test:end-to-end script added
* cypress and eslint-plugin-cypress moved to dev dependencies
* Run end-to-end tests at CI using end2end script
* cypress/screenshots/ added to gitignore
* end2end job added
* Dedicated docker image for Cypress
* Store videos and screenshots
* Prepare and store junit report
* Use junit reporter
* Code refactoring
* Code refactoring
* Code refactoring
* lint-staged for json, md and yml files
* Format json config
* Assert that PyPI - License is displayed
* Do not create fixtures
* feat: started refactoring codecov
* tests: removed erroneous test from draft PR
* chore: prettified for prettier
* feat: more codecov updates and tests
* feat: more codecov refactor updates
* feat: added codecov redirect content
* refactor: removed legacy codecov service file
* refactor(codecov): added redirect for legacy token route path
* docs(codecov): added documentation to examples for token info
* docs(codecov): updated vcs param in example patterns
* refactor(codecov): update redirect service date
Co-Authored-By: calebcartwright <calebcartwright@users.noreply.github.com>
* refactor(codecov): various updates based on PR feedback
* chore: added comment to codecov 401 test
This takes another pass over the modern services to remove unused code. I switched the shared code to use a function instead of a class and removed the indirection in the route params which led to skew between the route and examples and wasn't making things any clearer.
* Tweak Docker initialization
1. Set NODE_ENV=production in Docker.
2. When NODE_ENV is production, bind to all interfaces. This seems like a
sensible default.
3. Exclude Dockerfile from container to improve layer cacheability when
modifying the dockerfile.
Ref #3165
* Rm obsolete comment
* refactor(waffle)
* refactor(waffle): added joi schema
* tests(waffle): added unit tests for transform & render
* chore: added qs for waffle api call
* refactor(waffle): tweaked test names
* refactor(waffle): made label required param, added redirect for BC
* refactor(waffle): relax schema to handle missing colors and null labels
* chore: removed waffle label test no longer needed
* refactor(waffle): updated redirect service
* refactor(sourceforge): ref. sourceforge and add folder test (#3127)
doc: updated tutorial links and code snippets (#3124)
Refactor [Coveralls] (#3130)
* refactor(coveralls)
* chore: added comment with link to api
* doc: updated coveralls api doc comment
* doc: updated coveralls api doc comment
update clojars endpoint
Updates clojars badge to use api endpoints
Added release endpoint which returns latest stable release
Updates version endpoint which will now also return snapshots if available or latest stable release
check for invalid version and update variable send to render
import InvalidResponse
update require
make pretty
switch to prettyMessage
remove metadata lines
initial base class
initial base class
update schema
update ClojarsDownloads base class
simplify version classes
remove transform from export
update schema
remove unused var
replace == with ===
remove extra line
fix versionColor ?
fix lint error
make pretty
refactor transform
refactor transform and update tests
add error messagest to download service
fix error messages
remove errorSchema, revert changes to tests
refactor schema
update ClojarsDownloads base class
simplify version classes
remove transform from export
remove unused var
fix lint error
make pretty
refactor transform and update tests
add error messagest to download service
fix error messages
remove errorSchema, revert changes to tests
refactor schema
* fix versionColor
* remove errorMessages
* change prettyMessge to string
* update service names and add api docs reference
* update shields url
* update service names for clarity
* rename service files for clarity
* remove transform
* remove InvalidResponse
I did this as a warm-up to using [React hooks](https://reactjs.org/docs/hooks-intro.html), which provide a better way to accomplish stateful things and side effects using functional components. This allows all components to be written in the same style, improves testability, facilitates code reuse, etc.
There's [a intro here](https://reactjs.org/docs/hooks-intro.html) which links to [Dan's talk at React Conf](https://www.youtube.com/watch?time_continue=3599&v=dpw9EHDh2bM) which does a really good job of explaining why hooks are a good way to write components. He describes hooks as being the electrons and neutrons to components which are atoms. Low-level functionality which was always there in React, though not as accessibly or visibly.
This adds a lint rule that enforces "the rule of hooks" which says they have to be declared at the top level in the functional component.
I don't think this changeset does a fabulous job of showing off the improvements hooks allows, though I think it is still a good direction for this code.
* 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
This moves a few helpers from `lib/` to `services/`:
build-status.js
build-status.spec.js
color-formatters.js
color-formatters.spec.js
contributor-count.js
licenses.js
licenses.spec.js
php-version.js
php-version.spec.js
text-formatters.js
text-formatters.spec.js
version.js
version.spec.js
And one from `lib/` to `core/`:
unhandled-rejection.spec.js
The diff is long, but the changes are straightforward.
Ref #2832
The buildpack config doesn't seem to be needed. This would affect review apps, staging, and self-hosting.
Also, devDependencies are installed by default during the build: https://devcenter.heroku.com/changelog-items/1376
By removing `NPM_CONFIG_PRODUCTION=false` we allow these to be pruned so they're kept out of the slug. This also has the advantage of creating a test environment in PRs where missing production dependencies will cause things to break. That'd be a good thing!
This picks up #2068 by adding per-badge stats as discussed in #966.
It ensures every service has a unique `name` property. By default this comes from the class name, and is overridden in all the various places where the class names are duplicated. (Some of those don't seem that useful, like the various download interval services, though those need to be refactored down into a single service anyway.) Tests enforce the names are unique. These are the names used by the service-test runner, so it's a good idea to make them unique anyway. (It was sort of strange before that you had to specify `nuget` instead of e.g. `resharper`.)
I've added validation to `deprecatedService` and `redirector`, and required that every `route` has a `base`, even if it's an empty string.
The name is used to generate unique metric labels, generating metrics like these:
```
service_requests_total{category="activity",family="eclipse-marketplace",service="eclipse_marketplace_update"} 2
service_requests_total{category="activity",family="npm",service="npm_collaborators"} 3
service_requests_total{category="activity",family="steam",service="steam_file_release_date"} 2
service_requests_total{category="analysis",family="ansible",service="ansible_galaxy_content_quality_score"} 2
service_requests_total{category="analysis",family="cii-best-practices",service="cii_best_practices_service"} 4
service_requests_total{category="analysis",family="cocoapods",service="cocoapods_docs"} 2
service_requests_total{category="analysis",family="codacy",service="codacy_grade"} 3
service_requests_total{category="analysis",family="coverity",service="coverity_scan"} 2
service_requests_total{category="analysis",family="coverity",service="deprecated_coverity_ondemand"} 2
service_requests_total{category="analysis",family="dependabot",service="dependabot_semver_compatibility"} 3
service_requests_total{category="analysis",family="lgtm",service="lgtm_alerts"} 2
service_requests_total{category="analysis",family="lgtm",service="lgtm_grade"} 3
service_requests_total{category="analysis",family="snyk",service="snyk_vulnerability_git_hub"} 4
service_requests_total{category="analysis",family="snyk",service="snyk_vulnerability_npm"} 5
service_requests_total{category="analysis",family="symfony",service="sensiolabs_i_redirector"} 1
service_requests_total{category="analysis",family="symfony",service="symfony_insight_grade"} 1
service_requests_total{category="build",family="appveyor",service="app_veyor_ci"} 3
service_requests_total{category="build",family="appveyor",service="app_veyor_tests"} 6
service_requests_total{category="build",family="azure-devops",service="azure_dev_ops_build"} 6
service_requests_total{category="build",family="azure-devops",service="azure_dev_ops_release"} 5
service_requests_total{category="build",family="azure-devops",service="azure_dev_ops_tests"} 6
service_requests_total{category="build",family="azure-devops",service="vso_build_redirector"} 2
service_requests_total{category="build",family="azure-devops",service="vso_release_redirector"} 1
service_requests_total{category="build",family="bitbucket",service="bitbucket_pipelines"} 5
service_requests_total{category="build",family="circleci",service="circle_ci"} 5
```
This is predicated on being able to use Prometheus's [`rate()`](https://prometheus.io/docs/prometheus/latest/querying/functions/#rate) function to visualize a counter's rate of change, as mentioned at https://github.com/badges/shields/issues/2068#issuecomment-466696561. Otherwise the stats will be disrupted every time a server restarts.
The metrics only appear on new-style services.
This switches to the new mozilla add-ons API.
It's not a completely like-for-like replacement. I was able to replicate the version, users and rating badges but we no longer have total download stats. We've got weekly downloads instead, so I've redirected `/d` to the new `/dw`
closes#3079
While I was doing #3090 I realized the work in #3012 did not handle legacy services.
I tested this manually with `/librariesio/release/hex/phoenix.svg?color=blue` and it works.
This will definitely save time, and ensure more uniformity.
It moves the `createServiceTester()` calls to a different place from where I'd like them, though I'm happy to have them checked by the linter.
Closes#2701
This consolidates all the badge URL generation functions into a single place, and updates the rest of the calling code to use it. It renames some things and updates labels to bring the names into alignment with the current API.
Resolve#2027
This is a mid-sized PR that adds query param validation to BaseService and updates most of the services which use query param validation to use it. There are a couple minor tweaks I made along the way.
Fix#2676
* 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
If e.g. `3 :: Only` alone is specified in PyPI classifiers, use the `3` from it. But keep ignoring `* :: Only` when it occurs with other specified versions.
* 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.
* Endpoint page: improve formatting
Cherry-picked from #2906 (conflicts with that)
Partly addresses #2837 but does not resolve it
* Add badge customizer to the endpoint page
* Clean lint
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.
Fixes#2848
Appveyor briefly has a status of `starting` before the job begins, so adding `starting` to the list of `otherStatuses` to prevent the Appveyor badges from showing `invalid response data` during that window
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
It can be helpful to have some diagnostic pages for development and quality control. I added one here for the logos, which renders all the named logos in ?style=flat and ?style=social.
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.
Often when responding to bug reports it would be helpful to easily run an example failing badge URL. It takes a while to do that, because you have to copy and paste just the right part of the badge URL. This works on `img.shields.io` links as well as partial paths and should make this really easy. 💨
* Add semantic color keywords
This is based on the list I proposed at https://github.com/badges/shields/issues/1522#issuecomment-456455618. As I started documenting `default` I realized it didn't feel quite right. It's not semantic in relation to the content the way the others are, and it's also not the default left color. I changed it to `disabled` which isn't perfect, but seems better. I'm open to other suggestions.
I updated the documentation but the colors won't render correctly until this is deployed
Close#1522
* Reformat the aliases
* Pretty up the docs
* Reset whitespace changes
* Clean lint
This removes `LONG_CACHE` and its descendants, which was a feature that added `?maxAge` to the live preview badges in the frontend. Since they are all static that is no longer needed, as the static badges all have longer cache timeouts regardless.
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.
Just noticed this typo and that one of the essential parts of the specification
could be worded more clearly. It seems like the hardest to enforce with SaaS
companies, so I don't think the explicitness will hurt.
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.
`base.js` is pretty long and `_makeBadgeData` is one of the most complex
functions in it.
It's a pure function so it's easy to test in isolation. This moves the function into its own module and reorganizes the tests in a way that makes it evaluate what it's doing, and easier to test what is and isn't covered.
Ref https://github.com/badges/shields/pull/2796#discussion_r249251008
* 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
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
* Fix orange statuses
* Add test for partially succeeded build
* Add service test for partially succeeded builds
* Add service test for partially succeeded builds
- 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.
It's easy to push services that don't validate, because much of the tooling, including the service test runner and the service definition generator, do not validate all the services. This leads to errors that manifest in CI. It would be more helpful to see these errors sooner.
This moves the `validateDefinition()` check to `loadServiceClasses()`, where the services are first loaded, and fixes related validation errors.
Two of these regexes have triggered a LGTM alert.
https://lgtm.com/rules/1505904457770/
I’m not terribly concerned about it given this is a test, though it’s nice to clear these up, and the new regexes are a bit easier to understand.
* New Service: Bitbucket Server: Pull Request Count
* [Bitbucket]: Pull Requests: Add Support for bitbucket-server
* Update examples to use namedParams instead of exampleUrl
* Simplify cloud vs server check
* [Bitbucket]: Add support for bitbucket cloud private repos
* Add additional tests for bitbucket server
* [Bitbucket]: Add tests for basic auth
* [Bitbucket] Format secrets according to style guides
* [Bitbucket] Add link to server REST documentation
* Punt adding VSCode debug task to separate PR
* [Bitbucket] Remove extra truthy check on serverSecrets
* [Bitbucket] Fix credentials after rename
* [Bitbucket] Use query parameters for Bitbucket Server support
* Fix bitbucket creds in secret template
* [Bitbucket] staticExample -> staticPreview
* Remove VSCode specific gitignore entries
* [Bitbucket] Normalize pluralization of PullReqeust(s) to match file name
This code isn't being run during tests, though let's fix that later as part of #2733. Specifically:
> However _the pool itself_ could be used all the time; there's not a big advantage in turning that off when it doesn't need to be used.
Fix#2728
With the menu in place I think having more categories is helping that process because it's grouping more similar things together. Given #2722, improving our discoverability in the analysis area may be particularly useful to developers right now.
- With examples using `pattern`s, allow building the URL from its component parts, including the query string.
- Provide a button to copy the link, with an animation.
To enable this for other badges, convert them to use a `pattern`: #1961.
* bStats badges
* Remove inline tutorial comments
* Split tests into seperate files
* use shorthand for tester instantiation
* use Joi.number() for validation
* Misc. fixes
* update to use native api
Currently HTML code of shields.io contains two `<title>` elements. This PR removes an extra title element.
Before change:
```bash
> curl https://shields.io -s | egrep "<title.*/title>" -o
<title class="next-head">Shields.io: Quality metadata badges for open source projects</title>
<title>My page</title>
```
After change:
```bash
> curl http://localhost:8080 -s | egrep "<title.*/title>" -o
<title class="next-head">Shields.io: Quality metadata badges for open source projects</title>
```
The ranking endpoints return a value for every day. This is rare, but it looks like sometimes this can be `null` (for example if you call http://bestgems.org/api/v1/gems/rack/daily_ranking.json the rank was `null` on `2013-07-02` ) and if the rank has _ever_ been `null` for a package in the past, the schema will fail validating the response.
This modifies the schema to allow a `null` value and adds a case to handle if the rank is `null` today.
closes#2647
Based on some discussion/feedback here, this PR now contains several changes:
* Renames the `Sensiolabs` badge/service content to `SymfonyInsight` to reflect the rebranding of that product/service
* Refactors the original service to the new service model (using `BaseXmlService`)
* Updates the color scheme of the original/initial badge type (SymfonyInsight Grade) to more closely mirror the colors used by the vendor/service provider
* Adds a new badge type (violation counts/summary)
* Adds both mocked and live tests (there were none before) for both the grade & violation badges using the new path `symfony/i` as well as a couple tests for the old path `sensiolabs/i` to check for backwards compatibility
Refs #1358
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
Fixes#2571 (Really fixed this time 😄)
I attempted a fix in https://github.com/badges/shields/pull/2590 using fake timers but didn't realize how the timestamps being used in `cache-headers` were being created. This approach uses a dynamically generated `if-modified-since` value that will now be 30 minutes ahead of the server time stamp used in the comparison.
Because `server.js` was long a monolith, there are a bunch of shims in place to facilitate unit testing. A few of the test suites share port 1111 which means if one of them fails to set up, the port won't be freed and other unrelated tests will fail. Some of the tests which trigger server setup include timeouts which were added to give setup code time to run. In one the test suites, we actually modify `process.argv`, which seems completely gross.
This implements a few changes which improve this:
1. Separate the server from the server startup script, splitting out `lib/server.js`.
2. Inject config into the server and validate the config schema.
3. Inject config into the service test runner.
4. Use `portfinder`, a popular utility for grabbing open ports during testing.
5. Switch more of the setup code from callbacks to async-await.
Overall it leaves everything acting more reliably and looking rather cleaner, if in a few places more verbose.
It also fixes the root cause of #1455, a `setTimeout` in `rate-limit`. Off and on during development of this changeset, Mocha would decide not to exit, and that turned out to be the culprit.
Fix#1455
Please join me in welcoming @calebcartwright to the maintainer team!
Caleb has been doing an incredible job rewriting services, among other things, and we're glad to have him on board!
Fixes#2524
This PR addresses the issues expressed in #2524, in that it:
* checks if a server has advertised a FQDN it can be reached at and if that FQDN hosts Matrix's client APIs
* uses room aliases instead of room IDs, in order to avoid a badge being impossible to generate if the server that created the room leaves it
This includes a breaking change to the badge endpoint.
Ports the Nexus service to the new service model. Some related/relevant conversation in #2347 (and closes#2347). Also adds support for authentication which resolves#1699.
The CSS in the project is relatively difficult to change. While it is very DRY, it relies heavily on inheritance. It's difficult to make changes in the markup modal without it also affecting styles elsewhere.
[styled-components](https://www.styled-components.com/) is one of the leading CSS-in-JS libraries. By reducing dependency on global state and CSS inheritance, styles become explicit and are easier to inspect and change. It's also convenient that styles can be embedded with the components they modify.
At runtime, the library creates CSS classes, so it's pretty efficient.
We were using a little bit of [styled-jsx](https://github.com/zeit/styled-jsx) before, which ships with Next.js, though styled-components is more widely used and I've had good experiences with it all around.
In a few cases I've duplicated styles where it feels more natural to do that: for example, `text-align: center` is duplicated in `Main` and `MarkupModal`.
Much of this is a refactor, though there are a few visual changes, particularly in the markup modal and the style examples.
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`
See https://circleci.com/docs/2.0/collect-test-data/
This provides a list of failed tests in the Circle UI and a summary of which tests have failed. It should make interpreting test results easier
This adds a badge for collaborator count. When evaluating a library, it can be useful to know that there's not a single-contributor bottleneck for publishing. Having more than one collaborator is a sign of library maturity.
It adds another badge for dependency version of published dependencies, which solves a similar problem as the node-version badge. I will find this useful for making sure dependencies are up to date in a library.
The frontend has a few tests in `lib/` but not all of that is covered. The components are not covered at all. It's difficult to make changes to the frontend because you have to manually test that things haven't broken.
This PR uses [Enzyme](https://airbnb.io/enzyme/) to add some [shallow-rendering tests](https://github.com/airbnb/enzyme/blob/master/docs/api/shallow.md), which are essentially unit tests of the components.
This should pave the way for functional tests of the more complex components.
- The goal of this PR is:
- Consume the new service-definition format. (#2397)
- Make the frontend more readable.
- Behavior changes:
- I changed the **Image** field in the markup modal to show only the path.
- I added another click-to-select field below that shows the complete URL.
- This made it easier to suppress the live badge preview while it contains placeholders like `:user` or `:gem`, a minor tweak discussed at https://github.com/badges/shields/issues/2427#issuecomment-442972100.
- The search box now searches all categories, regardless of the current page. (This is an improvement, I would say.)
- I did not deliberately address performance, though I ripped out a bunch of anonymous functions and avoided re-filtering all the examples by category on every render, which I expect will not hurt. I haven't really tested this on a mobile connection and it'd be worth doing that.
- It would be great to have some tests of the components, though getting started with that seemed like a big project and I did not want to make this any larger than it already is.
It's a medium-sized refactor:
1. Replace `BadgeExamples`, `Category` and `Badge` component with a completely rewritten `BadgeExamples` component which renders a table of badges, and `CategoryHeading` and `CategoryHeadings` components.
2. Refactor `ExamplesPage` and `SearchResults` components into a new `Main` component.
3. Rewrite the data flow for `MarkupModal`. Rather than rely on unmounting and remounting the component to copy the badge URL into state, employ the `getDerivedStateFromProps` lifecycle method.
4. Remove `prepareExamples` and `all-badge-examples`.
5. Rewrite the `$suggest` schema to harmonize with the service definition format. It's not backward-compatible which means at deploy time there probably will be 10–20 minutes of downtime on that feature, between the first server deploy and the final gh-pages deploy. 🤷♂️ (We could leave the old version in place if it seems worth it.)
6. Added two new functions in `make-badge-url` with tests. I removed _most_ of the uses of the old functions, but there are some in parts of the frontend I didn't touch like the static and dynamic badge generators, and again I didn't want to make this any larger than it already is.
7. Fix a couple bugs in the service-definition export.
This is a little fix I’ve been meaning to make for a while. Normally it manifests in the codetally badge, but that badge isn’t working right now.
Here’s a static example, where the right text is wrapped in spaces:
https://img.shields.io/badge/foo-%20bar%20-blue.svg
The spaces get included in width computation, though I suppose ignored when the svg renders, resulting in bad letter spacing.
With this fix, it renders the same as
https://img.shields.io/badge/foo-bar-blue.svg
This starts the rewrite of the dynamic badges. I've pulled into BaseService an initial version of the query param validation from #2325.
I've extended from BaseJsonService to avoid duplicating the deserialization logic, though it means there is a bit of duplicated code among the three dynamic services. The way to unravel this would be to move the logic from `_requestJson` and friends from the base classes into functions so DynamicJson can inherit from BaseDynamic. Would that be worth it?
This introduces a regression of #1446 for this badge.
Close#2345
* Added matrix badge
* decreased the size of the matrix logo by more than 50%
* returning the size in fetch() instead of an object
* found another way to register a throwaway account (guest account). this one actually works on matrix.org, but I kept the old way as a backup method. also changed the POST from /members to /state because guest accounts didn't work with /members
* updated logo to a recolored version of the official logo
* Removed unnecessary comments.
Added documentation on how to create the badge URL.
Added a test that hits a real room to test for API compliance.
URLs are now obtained from getter functions.
Added JSON schema for the /state API request.
Improved state response filter.
Replaced example URL room ID to a dedicated testing room.
Made some error messages more helpful.
* correctly implemented requested changes
* changed color hex codes to constants
Now that we have [PowerShell Core](https://github.com/powershell/powershell) the cross-plat version of PowerShell... it'd be really cool to have a badge that shows the OS's that your module works on.
On the PowerShell Gallery, users can do this by using the tags `Windows` `MacOS` `Linux`. In this PR, I use the PowerShell Gallery API to grab the tags from that package and display `windows` `macos` `linux` if they exist.
The result is:

which aligns with Conda and Cocoapods
* Correct regex generation logic
* Refactor variable name
* Mock Azure DevOps test result summary API
* Add live tests
Updated mocked tests to use expected values for assertion. Added live
tests to test the API. Added `no tests` as an acceptable result for live
tests.
* Declare common nock setup functions to avoid repetition
- Badge shows number of questions for a given library for the previous month (not current month because its in progress)
- Service works for not just the StackOverflow site but for other StackExchange sites also
Close#2378
Added a test results badge service for an Azure Pipelines build using the ResultSummaryByBuild endpoint. Added basic unit tests for the service.
Close#2411
Three main goals:
1. In the front end:
a. Show form fields and automatically assemble badge URLs (#701)
c. Group together examples for the same service
b. Show deprecated services
2. Make it easy to changing the schema of `examples`, thanks to 100% validation. One challenge with frameworks is that when there are typos things fail silently which is pretty unfriendly to developers. The validation should really help with that. (This caught one bug in AUR, though I fixed it in #2405 which landed first.)
3. Produce a service definition export for external tool builders. (#776)
4. Build toward harmony between the front-end data structure and the `examples` key in the service classes. I aliased `staticPreview` to `staticExample` which starts this process.
The old format:
- Lacked a consistent machine-readable representation of the fields.
- Flattened multiple examples for the same service were flattened.
- Excluded deprecated services.
The new format improves a few things, too:
- It cleans up the naming. Since this file evolved over time, the names were a bit muddled (i.e. what was an example vs a preview).
- It duplicated information (like `.svg`). (I can imagine dropping the `.svg` from our badge URLs someday, which would make the URLs easier to read and maintain.)
- For a human reading the YAML file, providing the static example as a deconstructed object is more readable.
Here are a couple snippets:
```yml
- category: build
name: AppVeyorCi
isDeprecated: false
route:
format: '([^/]+/[^/]+)(?:/(.+))?'
queryParams: []
examples:
- title: AppVeyor
example: {path: /appveyor/ci/gruntjs/grunt, queryParams: {}}
preview: {label: build, message: passing, color: brightgreen}
keywords: []
- title: AppVeyor branch
example: {path: /appveyor/ci/gruntjs/grunt/master, queryParams: {}}
preview: {label: build, message: passing, color: brightgreen}
keywords: []
- category: downloads
name: AmoDownloads
isDeprecated: false
examples:
- title: Mozilla Add-on
example: {path: /amo/d/dustman, queryParams: {}}
preview: {path: /amo/d/dustman, queryParams: {}}
keywords: [amo, firefox]
```
There's a lot going on in this PR, though it's all interdependent, so the only way I can see to break it up into smaller pieces would be serially.
1. I completely refactored the functions for managing cache headers. These have been added to `services/cache-headers.js`, and in some ways set the stage for the rest of this PR.
- There are ample higher-level test of the functionality via `request-handler`. Refactoring these tests was deferred. Cache headers were previously dealt with in three places:
- `request-handler.js`, for the dynamic badges. This function now calls `setCacheHeaders`.
- `base-static.js`, for the static badges. This method now calls the wordy `serverHasBeenUpSinceResourceCached` and `setCacheHeadersForStaticResource`.
- The bitFlip badge in `server.js`. 👈 This is what set all this in motion. This badge has been refactored to a new-style service based on a new `NoncachingBaseService` which does not use the Shields in-memory cache that the dynamic badges user.
- I'm open to clearer names for `NoncachingBaseService`, which is kind of terrible. Absent alternatives, I wrote a short essay of clarification in the docstring. 😝
2. In the process of writing `NoncachingBaseService`, I discovered it takes several lines of code to instantiate and invoke a service. These would be duplicated in three or four places in production code, and in lots and lots of tests. I kept the line that goes from regex to namedParams (for reasons) and moved the rest into a static method called `invoke()`, which instantiates and invokes the service. This _replaced_ the instance method `invokeHandler`.
- I gently reworked the unit tests to use `invoke` instead of `invokeHandler`– generally for the better.
- I made a small change to `BaseStatic`. Now it invokes `handle()` async as the dynamic badges do. This way it could use `BaseService.invoke()`.
3. There was logic in `request-handler` for processing environment variables, validating them, and setting defaults. This could have been lifted whole-hog to `services/cache-headers.js`, though I didn't do that. Instead I moved it to `server-config.js`. Ideally `server-config` is the only module that should access `process.env`. This puts the defaults and config validation in one place, decouples the config schema from the entire rest of the application, and significantly simplifies our ability to test different configs, particularly on small units of code. (We were doing this well enough before in `request-handler.spec`, though it required mutating the environment, which was kludgy.) Some of the `request-handler` tests could be rewritten at a higher level, with lower-level data-driven tests directly against `cache-headers`.
It seems useful to accelerate #1961 even as the badge rewrites are still underway. This introduces a small amount of technical debt by hard-coding the static example, though continuing this work could allow us to eliminate the old ways of specifying examples. It seems like a decent tradeoff.
* Fix URL pattern for StackExchange Questions and Reputation per #2418
Url patterns have been changed back to their older legacy format.
Tests now run properly with this URL in addition to the examples
showing up on local.
* Make changes per review comments. Also change "q" to "t" parameter to match legacy url for questions
* TUTORIAL.md: Mention URL mapping upfront and clarify static meaning
* Be more specific that route is URL
* Explain async without reference to prior knowledge
* Use the same example URL to explain the directory layout
* Clean diff
* `route()` + `static`
- The route includes the base URL, so try to clarify that
- Add some more information about `static`
Per part of issue #2378, convert StackExchange service to the newer
BaseJson class. Refactor also to seperate StackExchange reputation and
questions tag info into new StackExchange subservice files
as the legacy class contained both which may be difficult to keep track
of in the future as the service continues to grow.
More tests have been added to make sure other StackExchange sites besides
StackOverflow will still work with the new badge setup.
* Allow to run service tests for remote shields instance
* Allow to run service tests for remote shields instance - doc
* Load testedServerUrl from env variable
* Load 'skipIntercepted' flag from env variable
JaCoCo uses "Line" as the type name for line coverage metric counter.
Added a condition to accept "Line" as a valid coverage stat label to
support JaCoCo style coverage reports.
See https://www.jacoco.org/jacoco/trunk/coverage/report.dtd for details
It does not make sense to check coverage for `next.config.js`. This file is run by the frontend build, which seems sufficient.
If that file has logic in it that is complex enough to warrant testing, it should be broken out into a separate file.
Avoids crashes in `server.spec.js` accompanied by this cryptic message:
```
Error: listen EADDRINUSE :::1111
at Object._errnoException (util.js:1022:11)
at _exceptionWithHostPort (util.js:1044:20)
at Camp.setupListenHandle [as _listen2] (net.js:1367:14)
at listenInCluster (net.js:1408:12)
at doListen (net.js:1517:7)
at _combinedTickCallback (internal/process/next_tick.js:141:11)
at process._tickDomainCallback (internal/process/next_tick.js:218:9)
```
e.g. https://circleci.com/gh/badges/shields/24094
These tests clearly should be refactored, though I’d like to get this fix in, in advance of a more involved refactor that shifts most of the responsibility away from this function. Maybe we can even eliminate at least one of these cases in the meantime.
There's a lot of demand for the Gitlab badges (#541) and the PR has been lingering, so I thought I'd start off one of the simple ones as a new-style service. This one is SVG-based, so it shouldn't require the API-token logic which could use some more testing and will require us to create an app and configure it on our server.
We don't have any validation in place for `queryParams`. Probably this should be added to BaseService, though for the time being I extracted a helper function.
Thanks to @LVMBDV for getting this work started in #1838!
Close#2334
To avoid merge conflicts, I've deferred removing the aliasing logic in `prepareExamples`. That whole function will be refactored momentarily, and there's also #2339 open.
Now that the static badge has been moved in #2284, next in line for cleaning out `server.js` is this “static badge, old format.” I imagine this route is _very, very old_. (I wouldn’t be surprised if it’s not used at all. I’d be curious to see some stats on that endpoint. If it's not regularly getting requests I could see dropping it.)
In the case of URLs which have permanently changed, an approach I’d like to try is issuing a 301 Redirect.
The benefit is that if a user pastes the URL into the address bar while they are previewing or editing it, the browser will replace the address with the corrected URL when it loads. I figure this will cause some people to update their URLs with no effort, simply because they previewed the badge in their browser, and others to change over, if they notice it.
We incur a slight cost, which is a second request. However many browsers cache the 301’s indefinitely, and we can set an effectively infinite cache duration so the CDN and most other downstream caches will keep them a long time. And handling the redirect is extremely cheap.
This is a nice way to preserve backward compatibility of old routes without having to complicate the new route, such as in the case of vso -> azure-devops. For maintenance purposes, the route that redirects can effectively be treated separately.
It’s also a nice, gentle, and confidence-inspiring way to signal that users should update their URLs.
We could generalize this code, though I think this is a good place to start. This route is tricky because it needs to be loaded last, complicating a reusable solution.
This continues the work from #2279, by allowing example badges to be specified using `namedParams`. Using an object makes it possible for us to display these in form fields down the line. (#701)
I've called this the "preferred" way, and labeled the other ways deprecated. I've also added some doc to the `examples` property in BaseService. Then I realized we had some doc in the tutorial, though I think it's fine to have a short version in the tutorial, and the gory detail in BaseService.
I've also added a `pattern` keyword, and made `urlPattern` an alias.
Closes#2050.
- Stop running daily service tests in the main repo (since they're now handled [over here](https://github.com/badges/daily-tests)
- Add coverage and separate daily tests badges with links to coveralls
- Update our coverage ignores
- Move scripts, which do not need coverage, into `scripts/`
- Split out coverage test for npm package
- Remove spurious env var
Ref: #1584#2314
This picks up @RedSparr0w's work in #1802.
1. The handler for the static badge is moved into its own service with a synchronous handler. Avoiding an async call may make the static badges slightly faster, though it may be worth profiling this if it turns out we want asynchronous static badges in the future. If it doesn't make a performance difference we could make this handler `async` like the others.
2. Most of the custom static-badge logic is in a BaseStaticBadge base class.
3. Rewrite the static Gitter badge to use BaseStaticBadge.
4. A bit of minor cleanup in related functions.
This simplifies and further optimizes text-width computation by computing the entire width table in advance, and serializing it in the style of QuickTextMeasurer (#1390). This entirely removes the need for PDFKit at runtime. This has the advantage of fixing #1305 – more generally: producing the same result everywhere – without having to deploy a copy of Verdana.
The lifting is delegated to these three libraries, which are housed in a monorepo: https://github.com/metabolize/anafanafo
I'd be happy to move it into the badges org if folks want to collaborate on maintaining them.
QuickTextMeasurer took kerning pairs into account, whereas this implementation does not. I was thinking kerning would be a necessary refinement, though this seems to work well enough.
I dropped in a binary-search package to traverse the data structure, in part to conserve space. This causes a moderate performance regression, though there is ample room for improving on that: https://github.com/badges/shields/pull/2311#issuecomment-439182704
When I deployed 5e99aad2de to s0, shortly after Sentry picked up an unhandled error. I'm not sure which of the legacy badges this is in.
The bug was introduced just now, in #2257. Oops!
A test would have caught this, but I don't think it's worth wrapping tests around this difficult-to-test code. It makes more sense I think, to refactor the remaining badges that use it, replace it with something using async/await (maybe based on [node-cache](https://www.npmjs.com/package/node-cache), and test that.
* move gh-badges files out of /lib
As far as possible, this is just moving files
around and updating paths however there are 2
functional changes in this commit:
- remove use of lib/register-chai-plugins.spec
in badge-cli.spec.js
- remove use of starRating()
in text-measurer.spec.js
* update service tests that use colorscheme.json
* split package.json in two
* clean up import
* don't hard-code path
* start a changelog
* put a license file in the package dir
* re-organise documentation 📚
* don't pack test files
* remove favicon from Makefile
* give package its own test command
* link the docs better in README
The NuGet badge examples are straggling in all-badge-examples. Rather than move them as is, I thought it made more sense to refactor the services and see if they could be generated. I didn't take that on here; this is a straight rewrite of the badges. The old implementations were fairly difficult to follow. The new implementations are complicated too, though I hope much more readable.
Though the NuGet behaviors could be consolidated into a single flag, I split `withTenant` and `withFeed` into separate flags, thinking naming the behaviors makes the implementations easier to understand. I defaulted these to true, thinking that really this is really a MyGet implementation which is generalized to NuGet. Though maybe it makes more sense to have the MyGet style as the default. Probably it doesn't matter much either way.
I added a helper class ServiceUrlBuilder to construct the Shields service URL. It's useful in this complex case where the URL must be built up conditionally. This might be useful in a couple other places.
I also wrote a new service to handle the Powershell badges. They've diverged a little bit from the Nuget v2. There's a bit of shared code which I factored out.
If the XML Nuget APIs are more reliable, we could consider switching everything else over to them, though for now I would like to get this merged and get #2078 fixed.
Fix#2078
All the recent circle builds are failing and when I re-ran a build on master, I'm seeing the same failure.
```
npm ERR! path /root/repo/node_modules/gh-badges
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall access
npm ERR! enoent ENOENT: no such file or directory, access '/root/repo/node_modules/gh-badges'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2018-11-12T14_28_41_232Z-debug.log
Exited with code 254
```
After reading https://discuss.circleci.com/t/cant-run-npm-install/19012 I wonder if it's related to the `working_directory` line. That issue suggests not using it.
The GitHub service family is the largest, and as yet untouched by our service rewrite. I thought I would start the process by tackling one service.
This pull request has a few things going on:
1. Rename pull-request-status to pull-request-check-state. We have another badge called pull request status. It seems like the checks are called one thing in the UI and another thing in the API, which is unfortunate. If other folks have strong feelings about the name, I’ll defer.
2. Move its tests and tighten up the syntax.
3. Move its badge examples including the doc string.
4. Add a new helper `errorMessagesFor` to use in the new services in place of `githubCheckErrorResponse`. It seems like we didn’t really use the `errorMessages` parameter to `githubCheckErrorResponse`, so I pared this down. I’m not sure if this is the function we’ll ultimately want, but it seems like a good place to start.
5. Pull fetch code I _know_ we use in other places into `github-common-fetch`. As in the PR I just opened for azure-devops, this takes a functional approach to the shared code, which is more direct, nimble, and easy to reason about than inheritance.
6. Create `GithubAuthService` which functions identically to BaseJsonService, except for one thing, which is that it uses the token pool. I accomplished this by adding a `_requestFetcher` property to BaseService, which is initialized to `sendAndCacheRequest` in the constructor, and can be overridden in subclasses. Since we weren’t using `_sendAndCacheRequest` directly except in BaseService and tests, I removed that property. I like this approach to patching in the GitHub auth because it’s very simple and creates no new API exposure. However, the way we’re doing the dependency injection feels a bit odd. Maybe the eventual refactor of request-handler would be a godo time to revisit this.
The GitHub requests go through many, many layers of indirection at this point. Later on it would be good to shave some of these off, perhaps once the legacy GitHub services have been converted, or when all the services are done and we can take another look at the base service hierarchy. The work in #2021 and #1205 is also related.
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`.
I went down a rabbit hole while trying to untangle the bug in the dockbit and bitrise examples https://github.com/badges/shields/pull/2234#pullrequestreview-169997546.
The URL generation code is spaghetti-like, with functions, many of which I wrote, with opaque names, doing similar but not identical things, and making slightly incompatible assumptions about the way query strings are handled.
I got a bit lost and need to take a step back.
Meanwhile, this is a small piece of work I did that’s worth keeping. It doesn’t scratch the surface of the tangle, but it does remove a bit of duplication.
It also makes a minor stylistic ES6 change in the handling of default arguments.
Ref: #2027
1. Add validation to BaseSvgScrapingService and update readthedocs accordingly.
2. Rewrite vso and add more tests. Rename it internally to azure-devops. URLs are still `/vso` for now. Should we make a way to let a service register multiple URL patterns?
3. Handle shared code using a functional pattern instead of inheritance. This comes from a discussion https://github.com/badges/shields/pull/2031#issuecomment-417893819. I like the functional approach because it's more direct, nimble, and easy to reason about; plus it allows services to grow from a family of one to two more easily.
* Basic process metrics
* Enable Prometheus by an environment variable
* Code formatting
* Documentation for Prometheus metrics
* Link from README to documentation of Prometheus
* Link from README to documentation of Prometheus
* Link from README to documentation of Prometheus
* Separate module for metrics + tests
* Metrics limited by IP
* Metrics are forbidded for all requets by default
* Code refactoring
* allowedIps passed as a string to PrometheusMetrics
* Handle missing config
* METRICS_PROMETHEUS_ALLOWED_IPS added to documentation
* Log info about enabled metrics
* Unused code removed
* package-lock.json updated
* prom-client updated to 11.1.2
* Code refactoring
* Do not read IP address from X-Forwarder-For header
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.
Continuing the work from #2234, this creates additional, empty LegacyServices to hold the badge examples for conda and cocoapods. It's an approach we could take to finish emptying out all-badge-examples while the refactoring continues.
On the website badge, even the first URL path component is variable. I didn't think it could be moved, but it can!
Based on discussion in #2031, this adds an abstract service for SVG badges. I started with Readthedocs and the other services can be done as a follow-on.
I called it **BaseSvgScrapingService** rather than **BaseSvgService** to clarify that it's for badges from svg source data – not svg badges, which is all the badges.
Since I don't expect the svg parsing function to be used anywhere else once the services are refactored, I moved it into the class. I added a default value for `valueMatcher`, which works on Shields-style badges and seems to be used more than once.
The tests are based on XmlBaseService. I added one for valueMatcher, and also moved the SVG parsing badge here. Testing on codacy + vso should ensure the old `fetchFromSvg` is still working.
* Upgrade babel 6.x to babel 7.0
* Next 6.1.1 + additional babel packages needed for Babel 7.0
* Add @babel/register
* use @babel/preset-env in babel.presets to enable babel.env configuration
I had to track down the right lint rule for this. We have no-useless-rename for destructuring and import/export. The one for object literals is object-shorthand.
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.
To run this requires renaming `private/secret.json` to `private/secret-production.json` in the working tree used for deployment.
Goals:
- Ensure production secrets are not used in development
- Avoid modifying the current working tree
- Avoid branch switching: make sure the current ref gets deployed
- If something other than `master` is deployed, leave `HEAD` alone; don't reset to `master`
- Ensure the build runs before server deploy (#1941)
This makes use of Git working trees, which is a relatively new but stable feature in Git. I was initially reluctant to use git worktree, mostly because I don't like adding new tooling that isn't necessary. The other alternative I experimented with was copying or re-cloning to an entirely separate working copy. This was messier and more brittle than using `git worktree`.
* define a public interface for NPM package
* move check-node-version to dependencies
* add missing file to package
* update docs
* bump version
* add gh-badges option to issue template
* abstract text measuring from users
* add a DocBlock for BadgeFactory.create()
Add some error messages for the developer when .service.js is malformed
When loading `.service.js` files which don’t contain services, such as when the export is forgotten, print helpful error messages. This will only occur during development; the unit tests will catch these problems well before code reaches the server.
* upgrade to Joi 14
Joi 14 throws an exception on regexes which use the `g` flag
see https://github.com/hapijs/joi/issues/1615
semver-regex uses the `g` flag
https://github.com/sindresorhus/semver-regex/blob/master/index.js
so in order to upgrade Joi, I've swapped out semver-regex
We'll use joi-extension-semver for semver validation now
* use isVPlusDottedVersionNClauses in jetbrains tests
some of these projects use version numbers like
v1.7 or
v3.0.0.141
In #2028 I suggested that we update as much of the code as possible to make consistent use of async await. This snags a bunch of the utility code and attempts to do that.
* Precommit hook with prettier and eslint added
* Info about running prettier removed from documentation
* Info about a pre-commit hook in documentation
- Fix case where app/branch exists but has no builds or CI runs
- Fix aplicationId/branch regex case
- Issue #2076:
- `ci/{projectId}` reports the result of a CI run
- `build/{applicationName}` reports the result of a build
- `ci/{applicationName}` reports the result of a _build_
(but isn't documented anywhere) for "backwards compatibility"
This picks up the work from #1321 on top of the work from #1940.
It allows the user to choose a compact tests format, or to override the labels with their own text or symbols.
I've rewritten the deprecated services using the `deprecatedService` helper from #1922. I added a test for `Deprecated`, and for `enforceDeprecation`, which isn't being used right now, but is there for future use.
This also makes it possible to write services using BaseService which do not have any named parameters (with a test).
Ref: #1358
This continues a consistency update we’ve been making to standardize on URL based on a recommendation from WHATWG: https://url.spec.whatwg.org/#goals
This also helps with copying and pasting between all-badge-examples and new-style services, where it’s otherwise easy to make a mistake.
Ref: #1322#1341
* allow service classes to define a static example
* define static example for some services
(apm, appveyor, cdnjs, clojars, gem, librariesio, npm, uptimerobot)
* add/update tests
This allows us to show an example without making an API call to a live service for better performance.
We can now specify 3 fields in the example definition:
* urlPattern for the version with placeholders e.g: /npm/dw/:package.svg
* ExampleUrl/Uri for the concrete example e.g: /npm/dw/localeval.svg
* PreviewUrl/Uri for the static (or live) image we will actually show
This is a bit of sugar that reduces the boilerplate for creating testers in what I expect will become the standard case: a service in `foo/foo-thing.service.js` with its tests in `foo/foo-thing.tester.js`.
This makes a small stylistic change, which is to name the service by its CamelCase class name rather than an invented snake-case ID. Whereas before the name was specified in `class FooThing extends Base[Json]Service` and a second time in the tester, it now only needs to be specified once.
- Move the Docker Pulls badge from **Other** to **Downloads**.
- Create **Platform & Version Support** for the following:
- django version support
- python version support
- node version support
- pypi - wheel (waiting to avoid conflict with #1922)
- pipi - format (waiting to avoid conflict with #1922)
- pipi - implementation (waiting to avoid conflict with #1922)
- hhvm
- cocoapods platform
- conda
- php version badges
This implements proposals 1, 2, and 4 from #1905:
* Move gem rank from ratings to downloads; tweak title
* Move docker build from other to build
* Move bundlephobia, github file, github repo, imagelayers, and microbadger size + layers badges into new category
* Fill in a couple missing titles
This is a fairly simple addition of a Redis-backed TokenPersistence. When GithubConstellation is initialized, it will create a FsTokenPersistence or a RedisTokenPersistence based on configuration. Have added tests of the Redis backend as an integration test, and ensured the server starts up correctly when a `REDIS_URL` is configured.
Ref: #1848
Instead of saving tokens on a timer, save them when they change. Use EventEmitter to keep the components loosely coupled.
This is easier to reason about, much easier to test, and better supports adapting to backends which support atomic operations.
This replaces json-autosave, which was a bit difficult to read and also hard to test, with fsos, the lower-level utility it’s built on.
Ref: #1848
- Log the response when using `test:services:trace`
- Fully log large nested objects
Since the `badgeData` is in a different format from the JSON response, and also doesn't include the title, including this output is helpful. It makes it clearer what the Joi matchers are trying to match.
Sometimes when there's a deep nested structure, it's helpful or necessary to see the entire thing.
We use arrow functions in most places; this enforces it.
Passing arrow functions to Mocha is discouraged: https://mochajs.org/#arrow-functions
This was a mix of autofixes and hand adjustments.
* InvalidParameter: New error type
* Return inaccessible for 5xx errors from services
* Add test for Inaccessible on 5xx
* Add tests for named error types
I ran into this while working on #1867, where ultimately I couldn't solve my problem by injecting config. This will make it easier in the future, though.
This creates a new convenience class which consolidates all the Github initialization. It supports dependency injection and facilitates refactoring the persistence along the lines of #1205.
Also ref #1848
When JSON responses come back, they are sometimes not in the format expected by the API. As a result we have a lot of defensive coding (expressions like `(data || {}).someProperty`) to avoid exceptions being thrown in badge processing. Often we rely on the `try` blocks that wrap so much of the badge-processing code, which catch all JavaScript exceptions and return some error result, usually **invalid**. The problem with this is that these `try` blocks catch all sorts of programmer errors too, so when we see **invalid** we don't know whether the API returned something unexpected, or we've made a mistake. We also spend a lot of time writing defensive tests around malformed responses, and creating and maintaining the defensive coding.
A better solution is to validate the API responses using declarative contracts. Here the programmer says exactly what they expect from the API. That way, if the response isn't what we expect we can just say it's an **invalid json response**. And if our code then throws an exception, well that's our mistake; when we catch that we can call it a **shields internal error**. It's also less code and less error-prone. Over time we may be confident enough in the contracts that we won't need so many tests of malformed responses. The contract doesn't need to describe the entire response, only the part that's needed. Unknown keys can simply be dropped, preventing unvalidated parts of the response from creeping into the code. Checking what's in our response before calling values on it also makes our code more secure.
I used Joi here, since we're already using it for testing. There may be another contracts library that's a better fit, though I think we could look at that later.
Those changes are in base.js.
The rest is a rewrite of the remaining NPM badges, including the extraction of an NpmBase class. Inspired by @chris48s's work in #1740, this class splits the service concerns into fetching, validation, transformation, and rendering. This is treated as a design pattern. See the PR discussion for more. There are two URL patterns, one which allows specifying a tag (used by e.g. the version badge `https://img.shields.io/npm/v/npm/next.svg`), and the other which does not accept a tag (e.g. the license badge `https://img.shields.io/npm/l/express.svg`). Subclasses like NpmLicense and NpmTypeDefinitions can specify the URL fragment, examples, the validation schema for the chunk of the package data they use, and a render function. The NpmVersion subclass uses a different endpoint, so it overrides the `handle` implementation from NpmBase.
The remaining services using BaseJsonService are shimmed, so they will keep working after the changes.
* add simple-icons
* handle undefined
* support logoColor param
* our icon > simple-icon
* dont crash ✅
* return false → undefined
* update test
* add test
* support logoColor on our logos
* cache as base64, pre-load-simple-icons, logo-helper
* add ?logoColor information
* and simple-icons reference, link to github master branch for our logos
* update simple-icons
update to 1.7.1
* Revert "and simple-icons reference, link to github master branch for our logos"
This reverts commit 5e99d5f8db.
* add link to simple-icons
* Add snapshot test
* support dash in place of space for logo name
- Present 'downloads', 'version', etc as pages
- Don't show any badges on the index page,
just links to categories.
- Tweak search so we can search all badges
from the index page, but without rendering
every badge as soon as we press a key.
* loosely detect semver versions
* semver loose validity
* add test
* semver compare versions when null
* add comments for loose
* remove console.log, only match semver scheme
* looser version restrictions
* re-sort version tests
comments refered to incorrect test
* add support for pre-release tags
#1682
* support uppercase, lowercase mixed
* make pre-release opt in
* change pre param to object
* add notes
* hide left side if no text
* fix whitespace at start of template
* for-the-badge done
* center text
* add logo support
* update snapshot test
* make first - in static badge optional
* add no label support to non static badges
* Add test for label
* update to not allow use of false/0/null
* fixup
I’m guessing something has changed with the way rounding happens in bundlephobia. I don’t expect this to happen again, but if it does we can change this to a regex.
This causes extremely strange failures in CircleCI. `npm install`, oddly, rewrites and reformats package.json. We hash package.json to determine the cache keys, and oddly enough Circle computes a new hash when we write the cache. `npm-install` writes to one cache key. The tasks that follow read from another. Nothing runs.
I'm running into this because I'm using prettier auto-format on another project, and the presence of a `.prettierrc` means it's started trying to format Shields code.
In separate news, I'm loving auto-formatting!
* tell browsers and downstream caches to cache for
`env.BADGE_MAX_AGE_SECONDS`, default 0 for dev
* set Cache-Control: no-cache, no-store, must-revalidate if maxAge=0
* add servertime badge to help with cache header debugging
* if service category is 'debug', exclude from examples
* ignore maxAge GET param if less than `env.BADGE_MAX_AGE_SECONDS`
This addresses some long-standing comments in https://github.com/badges/shields/issues/1458#issuecomment-368270996
We should also adopt Gatsby, create-react-app, or something similar designed for static sites, to eliminate the unnecessary runtime dependency on Next.js while also letting someone else maintain our front-end tooling. :-D These alternative tools might work just fine in subdirectories without config, and we might be able to leave Jekyll turned on (though we don’t need it). However these git-related changes are orthogonal.
- Don’t check out master, making it possible to deploy the currently checked-out commit
- Disable Jekyll which we don’t need. This allows _next folders to be deployed, and the related URL rewriting to be removed.
- Completely empty the deploy branch’s index before deployment. This prevents errors from broken symlinks, while preserving the commit history in the deploy branch.
- Do the deployment work in a git working tree. This requires Git 2.18 but makes it possible to do the above very safely.
This was designed as part of a rewrite of the Github auth code in #1205 which is stalled because I don't want to deploy it without access to server logs. The need for token rotation came up recently in #541, so I picked up this code, removed the github-specific bits, and pulled it in. Ordinarily I wouldn't merge helper code without a use, though sadly it seems like the best way to move forward this rewrite.
* add support for rgb, rgb, css named colors
* add support for hsl, hsla & add color-validate
* update makeBadge test, better coverage
* re-add comment
* add comment for supported colors
* dynamic badge gen, remove 'hex'
* add support for 1.0 opacity & fix 101-109
* fix colorscheme tests
* remove extra tests
* add test for negative values
* add test for uppercase & mixed case colors
* fix mixed case/uppercase test
* allow whitespace around color
* update test error messages
* add comments
* add more uppercase test
* update error message
* default to grey/red if invalid color chosen
default colorscheme:
colorA: grey
colorB: red
* Revert "default to grey/red if invalid color chosen"
This reverts commit 10db0c6d74.
Reverted as this affects the CLI version/when no color specified.
* validColor -> isCSSColor
* assignColor function
* update tests to use sazerac
* Add Jenkins Jacoco coverage badge
* [Jenkins] add service test for jacoco coverage
* Added Jenkins Coverage (Jacoco) in all-badge-examples page
* Defined variables using let/const instead of var
* Used template string for the uri
* Used checkErrorResponse helper function for the error check
* Used NaN method for not a number test
* Prefixed the original Jenkin coverage test with "cobertura:"
* Moved the happy test case at front
* Merge the business logic between jacoco and cobertura
* Fixed lint issue
* Trigger notification
fix [waffle] labels badge
- update URL and parsing code to use /columns endpoint
- add error handling for 'not found' case
- add missing test cases
- update home page example
Closes#1731
* update nock
The version we were using didn't allow
regex pattern with allowUnmocked option.
Update to latest version which includes this patch:
https://github.com/node-nock/nock/pull/1068
* update codeclimate test to allow any snapshot id on second call
This test was failing because the
snapshot id changed for some reason.
This change allows that to happen
and we will still intercept the
second API call.
* upgrade danger.js to latest version
* If PR contains tests using assert, suggest expect syntax
* if PR touches service, check service tester also touched
* Basic version of commit-status badge added
* Support for case with no common ancestor
* Handle unknown branch
* Service tests with error responses
* Handle unexpected 404 responses from github
* Branch is a base
* Tests reordered
* Using not the newest commit in tests
* Test for checked commit identical with the newest commit in branch
* Code refactoring
* Example for Github commit merge status
* Color fix for Docker Hub automated integration
* Test for overriding colorB in docker stars badge
* Test for overriding colorB in docker pulls badge
* #008bb8 is color of automated docker builds
* Test for overriding colorB in docker build badge
* Overriding colorB in docker stars badge
* Overriding colorB in docker pulls badge
* Overriding colorB in docker automated badge
* Better assertions in docker tests
* The default docker color updated to match the logo
* allow services to export >1 classes
This change to loadServiceClasses() allows us to define
services which either export a single service class e.g:
module.exports = class Cdnjs extends BaseService {
//...
}
or more than one. e.g:
module.exports = {
GemVersion,
GemDownloads,
GemOwner,
GemRank,
}
* refactor ruby gem badges
- move badge code to service classes
- throw exceptions for errors
- use let and const
- change tests to expect 'downloads' label for error badges
- general tidying
* fix typo in tests
* Don't always use class name in example label
This allows (for example) GemVersion and GemDownloads
both to use the example label 'Gem'
* The most recent code examples in tutorial
* An extra empty line removed
* An extra escapring characters removed
* checkErrorResponse mentioned in tutorial
* Typo fix in tutorial
* Static badges as examples in tutorial
* Missing word in the tutorial added
* Typo fix in tutorial
* pass error object to InvaildResponse()
this prevents us from throwing
TypeError: Cannot read property 'stack' of undefined
when we attempt to parse invalid json
* refactor [cdnjs] integration
* Support for buildkite
* Added to the examples as well
* Removed the unnecessary label property
* Fixed the example
* Improve the tests
* Made the branch optional and review suggestions
* Added network error test
* Unexpected response test
* PR review suggestions
* Updated test to include all responses
* Forgot one of the tests
* Add dynamic yaml badge
* Forgot package lock
* Switch tests to yaml data source
* Add yaml to the dynamic badge maker options
* Reorder to match documentation examples
* Reordered dynamic types to be alphabetical
* Removed regex as pinend commit makes it unnecessary and fixed url
* Removed unused import
* Add more YAML MIME types
* Removed duplicate tests which don't differ between data types
Make a clear distinction between programmer errors ("internal errors") and runtime errors, and allow configuring the server to let the programmer errors bubble up in development and unit testing. This saves a huge amount of time because it generates ordinary stack traces when things go wrong. And, if these errors occur in production, we'll catch them, and display **shields | internal error** which is the equivalent of a 500 error.
Instead of centralizing examples, specify them from within a service.
* Avoid duplication in service loading + refactor
* Avoid duplication in URLs, rename uri -> url in BaseService
This resolves the following error occurring in production:
```
TypeError: Cannot read property 'slice' of null
/home/m/shields/lib/suggest.js in twitterPage at line 63:31
const schema = url.protocol.slice(0, -1);
```
This resolves the following error occurring in production:
```
TypeError: Cannot read property 'slice' of null
/home/m/shields/lib/suggest.js in findSuggestions at line 40:33
const userRepo = url.pathname.slice(1).split('/');
```
We’ve cleared the backlog of pull requests needing adoption and closed the old ones out, so it seems best to remove this from the contributing guidelines.
* Set request options for dynamic json badges to include accept header of application/json and json:true
* Added headers for XML dynamic badges
* Added tests for dynamic badges to check correct Accept headers are set
This merges the `node-8` branch. The heavy lift was by @Daniel15 with refactoring from me and a patch by @RedSparr0w.
* New API for registering services (#963)
* Disable Node 6 tests on node-8 branch (#1423)
* BaseService: Factor out methods _regex and _namedParamsForMatch (#1425)
- Adjust test grouping
- Rename data -> queryParams, text -> message
* BaseService tests: Use Chai (#1450)
* BaseService: make serviceData and badgeData explicit and declarative (#1451)
* fix isValidStyle test (#1544)
* Run tests in Node 9, not Node 6 (#1543)
These tests should fail if something is accidentally changed that affects the SVG or JSON files. In the case of deliberate changes, we can update the snapshots.
* remove newlines from datauri
* update test, remove decode
* support multiline datauris
* replace whitespace before checking isDataUri
removed multiline support from regex
* prependPrefix set default as empty string
* update
* add dynamic xml badge support
* add tests
* dynamic badge add tests for query param
* remove try catch
* use `checkErrorResponse()`
* update tests
* [dynamic json] add test for multiple items
* Rebase, [dynamic xml] Add support for multiple items
* 404 response -> resource not found
* multiple results test less greedy regex
still alot of room for improvement to this test
* update dynamic badge gen
* add dynamic xml gen tests
* update tests id & path
* datalist -> select
* uri -> url
kept support for uri, incase of any already existing badges.
* split dynamic gen uri
* update query placeholder
Gratipay is gone :(
For #1359
This failure from https://circleci.com/gh/badges/shields/1411?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
```
7) Gratipay
Receiving
[ GET http://localhost:1111/gratipay/Gratipay.json ]:
ValidationError: child "value" fails because ["value" with value "invalid" fails to match the required pattern: /^\$[0-9]+(\.[0-9]{2})?\/week/]
at Object.exports.process (node_modules/joi/lib/errors.js:190:19)
at internals.Object._validateWithOptions (node_modules/joi/lib/types/any/index.js:669:31)
at module.exports.internals.Any.root.validate (node_modules/joi/lib/index.js:139:23)
at Object.pathMatch.matchJSONTypes (node_modules/icedfrisby/lib/pathMatch.js:303:9)
at node_modules/icedfrisby/lib/icedfrisby.js:703:10
at IcedFrisbyNock._invokeExpects (node_modules/icedfrisby/lib/icedfrisby.js:1294:33)
at start (node_modules/icedfrisby/lib/icedfrisby.js:1274:12)
at Request.runCallback [as _callback] (node_modules/icedfrisby/lib/icedfrisby.js:1232:16)
at Request.self.callback (node_modules/request/request.js:186:22)
at Request.<anonymous> (node_modules/request/request.js:1163:10)
at IncomingMessage.<anonymous> (node_modules/request/request.js:1085:12)
at endReadableNT (_stream_readable.js:1056:12)
at _combinedTickCallback (internal/process/next_tick.js:138:11)
at process._tickDomainCallback (internal/process/next_tick.js:218:9)
```
* closes#1499 - update hhvm service
http://hhvm.h4cc.de... -> https://php-eye.com/api/v1/package...
* fix typo
* add switch breaks
* typo
* const & let vs var
* hhvm service tests
* unused const/var
* alias master & dev-master
* improved status messages - repo not found, branch not found
better tests: including invalidJSON fixture
* add service tests for NuGet v2 services
* fixup - test the correct endpoint
* remove superfluous try/catch blocks
* test the colors too
* use invalid json fixture
* Integrated Vaadin service to server.js & load age from color-formatters lib
* Added 8 tests for Vaadin services
* Added Vaadin badge to main page under Misc
* Used checkErrorResponse() and fix 404 test return value
* Removed maturity from URL field option
* Remove duplicate `age` module import
* Removed comment
* Changed several URI fields and fixed according tests
* Service tests for NPM total downloads
* Spread syntax removed
* service-tests/helpers/mocks.js -> service-tests/helpers/response-fixtures.js
* Another value an invalid JSON in response-fixtures
* Using invalidJSON helper in service tests
* Working example in a service test of microbadger
* isPercentage supports decimal and integer values
* Added a shield for calculating npm bundle sizes
* Fix linting errors
* Fixed badges for bundlephobia
* Remove un-required keywords
* Simplified handler based on feedback
* Use isFileSize for validation
* Convert camel-cased error codes to space separated ones
* Updated error format
* Fixed error formatting
* Renamed gzip to minzip
* Fixes lint error
* Remove test that times out
* refactor tests to make it more readable
* meaningless change
* use trim
* service tests for [cocoapods]
* Add tests for CocoaPods Endpoints
Bug fixes:
* Call `metrics.cocoapods.org` API endpoints over HTTPs
* Show correct left-side badge text on error in version/platform/license badges
* Handle null doc coverage gracefully
* Add handling for 'not found' responses
* drop last param to checkErrorResponse
* remove redundant line
* set badge label using more terse notation
* specify allowed platform values
* Fixed remaining CodeClimate badges
* Added explicit percentage keyword and dropped top level URL
* Merged the two badge handlers into one
* Removed trailing space
* Switched to "dash" URL style
* Reinstated top-level URL
* Swicthed to use letter as optional keyword
* Updated badge examples
* Cleaned up
* Changed badge label to technical debt
* Switched tests to more mainstream projects as previous ones were deleted
* Rearranged badge URLs and default formats
* Updated examples
* add test suite to formalise existing behaviour of shippable service
* throw more descriprive errors, use es6 declarations
* switch from SVG parsing to shippable API
* add test case for unexpected status code
* remove unused import
* link to source for status codes
* Show logos on social badges
* Revert "Showcase logos in social badges on the front page"
This reverts commit 61fa22b7e4.
* Update footer badges to all be social style
as per reverted commit 61fa22b7e4
Rather than depend on Shields production, use the GitHub auth info from CI. It's disorienting to have our own CI go down when production is down. It also makes it harder to review PRs when there are ops issues.
* [FIX] error colorscheme
* throw error if jsonpath query non existent
* fixup
* show brightgreen badge by default
* update test
* let -> var
* set lightgrey when no uri specified
* update tests
* red color for no uri specified
* dynamic badge use setBadgecolor()
* add tests for ruby gems version badge
* add tests for ruby gems users badge
* add tests for ruby gems rank badge
* add tests for ruby gems downloads badges
* don't allow 0th rank
* move version info to left side of badge
* fix: update nodejs version to latest LTS, to fullfill check-node-version. close#1437
* docs: add docker run example without shields.env file, because there is no such file in a repo and container wont start
* fix: docker build project, clean npm and run production mode. close#1373
For #1359
This failure from https://circleci.com/gh/badges/shields/1411?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
```
26) Uptime Robot
Uptime Robot: Percentage (valid)
[ GET http://localhost:1111/uptimerobot/ratio/m778918918-3e92c097147760ee39d02d36.json ]:
ValidationError: child "value" fails because ["value" with value "99.992%" fails to match the required pattern: /^[0-9]+%$/]
at Object.exports.process (node_modules/joi/lib/errors.js:190:19)
at internals.Object._validateWithOptions (node_modules/joi/lib/types/any/index.js:669:31)
at module.exports.internals.Any.root.validate (node_modules/joi/lib/index.js:139:23)
at Object.pathMatch.matchJSONTypes (node_modules/icedfrisby/lib/pathMatch.js:303:9)
at node_modules/icedfrisby/lib/icedfrisby.js:703:10
at IcedFrisbyNock._invokeExpects (node_modules/icedfrisby/lib/icedfrisby.js:1294:33)
at start (node_modules/icedfrisby/lib/icedfrisby.js:1274:12)
at Request.runCallback [as _callback] (node_modules/icedfrisby/lib/icedfrisby.js:1232:16)
at Request.self.callback (node_modules/request/request.js:186:22)
at Request.<anonymous> (node_modules/request/request.js:1163:10)
at IncomingMessage.<anonymous> (node_modules/request/request.js:1085:12)
at endReadableNT (_stream_readable.js:1056:12)
at _combinedTickCallback (internal/process/next_tick.js:138:11)
at process._tickDomainCallback (internal/process/next_tick.js:218:9)
27) Uptime Robot
Uptime Robot: Percentage (valid, with numberOfDays param)
[ GET http://localhost:1111/uptimerobot/ratio/7/m778918918-3e92c097147760ee39d02d36.json ]:
ValidationError: child "value" fails because ["value" with value "99.967%" fails to match the required pattern: /^[0-9]+%$/]
at Object.exports.process (node_modules/joi/lib/errors.js:190:19)
at internals.Object._validateWithOptions (node_modules/joi/lib/types/any/index.js:669:31)
at module.exports.internals.Any.root.validate (node_modules/joi/lib/index.js:139:23)
at Object.pathMatch.matchJSONTypes (node_modules/icedfrisby/lib/pathMatch.js:303:9)
at node_modules/icedfrisby/lib/icedfrisby.js:703:10
at IcedFrisbyNock._invokeExpects (node_modules/icedfrisby/lib/icedfrisby.js:1294:33)
at start (node_modules/icedfrisby/lib/icedfrisby.js:1274:12)
at Request.runCallback [as _callback] (node_modules/icedfrisby/lib/icedfrisby.js:1232:16)
at Request.self.callback (node_modules/request/request.js:186:22)
at Request.<anonymous> (node_modules/request/request.js:1163:10)
at IncomingMessage.<anonymous> (node_modules/request/request.js:1085:12)
at endReadableNT (_stream_readable.js:1056:12)
at _combinedTickCallback (internal/process/next_tick.js:138:11)
at process._tickDomainCallback (internal/process/next_tick.js:218:9)
```
To fix service test that fails in CI (due to no github auth) https://github.com/badges/shields/issues/1359#issuecomment-354184074
- DRY getPhpReleases()
- Pass named options to regularUpdate
- Add json option
- php-version: Move helpers before functions, and move exports to end
- Avoid mutating the inputs
- Declare all the input and output keys
- Avoid recomputing escapeXml on the same values
- Capitalize social badge labels before measuring
* twitter | add error text
inaccessable = 404 etc
invalid user = no data returned from endpoint
invalid = error thrown
* Twitter add tests
* add test for twitter url badge
Ref: #1379
This takes a naive approach to font-width computation, the most compute-intensive part of rendering badges.
1. Add the widths of the individual characters.
- These widths are measured on startup using PDFKit.
2. For each character pair, add a kerning adjustment
- The difference between the width of each character pair, and the sum of the characters' separate widths.
- These are computed for each character pair on startup using PDFKit.
3. For a string with characters outside the printable ASCII character set, fall back to PDFKit.
This branch averaged 0.041 ms in `makeBadge`, compared to 0.144 ms on master, a speedup of 73%. That was on a test of 10,000 consecutive requests (using the `benchmark-performance.sh` script, now checked in).
The speedup applies to badges containing exclusively printable ASCII characters. It wouldn't be as dramatic on non-ASCII text. Though, we could add some frequently used non-ASCII characters to the cached set.
Add a class which applies display: none to badges we don’t want to see. This is accomplished by passing a `shouldDisplay` function along with each badge, which pulls the current query through a closure and applies it.
A bit roundabout, but it works.
The rest of the changes are refactors to avoid code duplication.
I decreased the debouce rate to 50, which seems to work well.
Fix#1314
I have a branch going to automatically generate stats on which services have tests, and make a line chart over time. I'm having a lot of fun with that so I'll keep at it.
Meanwhile, here is my subjective list of critical services, for #1358.
IcedFrisby/IcedFrisby#71 will allow us to set a per-test `timeout()` and per-test `retry()`, which should allow us to keep flaky tests green most of the time.
A slough of service tests are failing locally, though they are also failing in master and seem unrelated to these changes. (#1359)
IcedFrisby is maturing toward a 2.0 API. There's been one breaking change to the way dependencies are installed, and probably more changes to come in the API itself. Shields uses such a small part of that API that 2.0, when it's released, may not even affect us.
… so we can stop saying "you forgot to…" in code review. 😀
This idea has come up a number of times. If we can write code to detect a contributor guideline, this tool will message the contributor automatically in a pull request. This lets people fix their own problems, relieves maintainers and reviewers from nagging, and keeps anyone from having to constantly ask for more tests.
For futher reading:
- [How to use Danger well](http://danger.systems/js/usage/culture.html)
- [Examples of the kind of thing it can do](http://danger.systems/js/)
- [Dangerfile reference](http://danger.systems/js/reference.html)
I don’t like that our build goes red on master all the time due to flaky service tests. I thought I’d look into other CI services that would make it possible to run the scheduled tests nightly without causing those messages to show up.
CircleCI, Heroku CI, and Codeship were obvious choices. Heroku CI wasn’t free and I didn’t have any experience with Codeship, so I looked into CircleCI. I’ve used their 1.0 system a lot though this was my first time on their 2.0 system. As with earlier versions, they’ve put a lot of work into making the build fast – perhaps more than any other CI system I’ve seen.
I had such good results, my goal shifted from scheduled daily builds (that don’t litter our commit history with red builds) to improving the CI experience as a whole.
This change made a big impact:
- Build logs load much, much faster. In the test I just ran, 22 seconds to < 2 seconds, a 90% improvement.
- Status of each step shows up right in the GitHub UI, which makes it much faster to see exactly what’s failed.
- Builds run about 50-75% faster on account of parallelism.
- GitHub service tests are fixed. This has been a long-standing issue.
- Ability to ssh into a build container to debug failures.
Here’s what I did:
- Created custom Docker images with our dependencies. To be honest, I’m not even sure these are necessary, only to install the greenkeeper-lockfile. We could get dejavu from npm. They make startup very fast.
- Created an npm-install stage which loads all dependencies into node_modules and caches them.
- Created separate stages for our main tests, service tests, and frontend tests, and stages to run the main tests and service tests in Node 6. These run in parallel, up to four at a time.
- Separated service test ID output from the service test results themselves. (I check these often during the PR process, when I confirm that service tests actually ran. Because the production Shields server caches the title, after updating it you can’t tell whether the update is taking effect.)
- Added a personal access token for the shields-ci user. This should actually fix the long-standing issue #979. CircleCI provides an option to “Pass secrets to builds from forked pull requests,” which means unlike Travis, they’ll give us enough rope to shoot ourselves in the foot.
- Schedule a daily build, which runs all the service tests.
* Add test suite for BitBucket service integration
* Present BitBucket issues as a metric (for consistency with BitBucket PR endpoint and GitHub endpoints)
* Factor out a shared regex
* Fail cleanly if count is `undefined`
- Fix issue in Firefox 57 when run from static build
- Fix color parameter in dynamic badge maker
- Correctly apply maxAge in usage badges
- Follow the WHATWG lead and begin to standardize on URL, not URI (https://url.spec.whatwg.org/#goals)
Both of the depcheck's are throwing errors
OS: `Windows 10`
Node: `v8.7.0`
Current Output:
```cmd
npm run frontend-depcheck
> gh-badges@1.3.0 frontend-depcheck C:\Users\Dan\Documents\GitHub\shields
> check-node-version --node '>= 8.0'
C:\Users\Dan\Documents\GitHub\shields\node_modules\semver\semver.js:678
throw new TypeError('Invalid comparator: ' + comp);
^
TypeError: Invalid comparator: '
at Comparator.parse (C:\Users\Dan\Documents\GitHub\shields\node_modules\semver\semver.js:678:11)
at new Comparator (C:\Users\Dan\Documents\GitHub\shields\node_modules\semver\semver.js:662:8)
at C:\Users\Dan\Documents\GitHub\shields\node_modules\semver\semver.js:828:12
at Array.map (<anonymous>)
at Range.parseRange (C:\Users\Dan\Documents\GitHub\shields\node_modules\semver\semver.js:827:13)
at Range.<anonymous> (C:\Users\Dan\Documents\GitHub\shields\node_modules\semver\semver.js:769:17)
at Array.map (<anonymous>)
at new Range (C:\Users\Dan\Documents\GitHub\shields\node_modules\semver\semver.js:768:40)
at C:\Users\Dan\Documents\GitHub\shields\node_modules\check-node-version\index.js:119:32
at module.exports (C:\Users\Dan\Documents\GitHub\shields\node_modules\map-values\index.js:9:18)
npm ERR! Windows_NT 10.0.16299
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\Dan\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js" "run" "frontend-depcheck"
npm ERR! node v8.7.0
npm ERR! npm v4.3.0
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! gh-badges@1.3.0 frontend-depcheck: `check-node-version --node '>= 8.0'`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the gh-badges@1.3.0 frontend-depcheck script 'check-node-version --node '>= 8.0''.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the gh-badges package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! check-node-version --node '>= 8.0'
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs gh-badges
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls gh-badges
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! C:\Users\Dan\AppData\Roaming\npm-cache\_logs\2017-12-04T00_30_04_974Z-debug.log
```
```cmd
npm run server-depcheck
> gh-badges@1.3.0 server-depcheck C:\Users\Dan\Documents\GitHub\shields
> check-node-version --node '>= 6.0 < 9.0'
The system cannot find the file specified.
npm ERR! Windows_NT 10.0.16299
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\Dan\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js" "run" "server-depcheck"
npm ERR! node v8.7.0
npm ERR! npm v4.3.0
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! gh-badges@1.3.0 server-depcheck: `check-node-version --node '>= 6.0 < 9.0'`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the gh-badges@1.3.0 server-depcheck script 'check-node-version --node '>= 6.0 < 9.0''.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the gh-badges package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! check-node-version --node '>= 6.0 < 9.0'
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs gh-badges
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls gh-badges
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! C:\Users\Dan\AppData\Roaming\npm-cache\_logs\2017-12-04T00_32_13_243Z-debug.log
```
Looks like its due to `'` being used around the version rather than `"`.
This PR Output:
```cmd
npm run frontend-depcheck
> gh-badges@1.3.0 frontend-depcheck C:\Users\Dan\Documents\GitHub\shields
> check-node-version --node ">= 8.0"
```
```cmd
npm run server-depcheck
> gh-badges@1.3.0 server-depcheck C:\Users\Dan\Documents\GitHub\shields
> check-node-version --node ">= 6.0 < 9.0"
```
- Periodically log github auth information
- Tokens are hashed which reduces the security risk inherent in the logs
- A consistent hash is used so tokens can be correlated across the three data structures and across the three servers
- Add an admin endpoint for github auth information
- Tokens are returned as-is to enable troubleshooting (e.g. comparing our reqRemaining to github’s)
While working on #1288 I configured frontend tests. I'm going in a different direction with that, though it seems worth keeping the test configuration. I added tests for one of the helper methods.
- Heroku reads the Node version from package.json. We're about to upgrade to Node 8 so this change to `engines` is only pre-emptive. It won't have any effect on the production servers.
- The production deploy scripts were missing the frontend files. This fixes that.
- This modifies the build setup to allow `BASE_URL=/`, which makes all requests relative to the page itself. That simplifies deploying the "debugging" frontend to the production servers, and makes it easy to host the frontend on Heroku.
I rewrote the frontend in React using a module bundler. It's matched feature-for-feature with the current frontend, with only slight changes in the styling. I did not fuss about making the styling identical; the badge popup looks particularly different.
This makes the front end much easier to develop. I'm really looking forward to implementing #701, to which this paves the way.
This makes light use of Next.js, which provides webpack config and dev/build tooling. We’ll probably replace it with create-react-app or our own webpack setup because unfortunately it comes with a lot of runtime overhead (the build is 400k).
Let’s open new issues for bugs and features, and track other follow-ups here: https://github.com/badges/shields/projects/1
- Support single-server testing and a local dev server (like Next) that is on a different port from the shields server
- Refactor config schema
With this change, the suggestions work locally in #1273.
The version in Shields goes back to last August. I reviewed the commits and didn't see any obvious incompatibilities. Hopefully @espadrine can weigh in!
Provide greater consistency for badges related to versions. Fix#1181.
- the `version` function in `color-formatters` was previously returning the colour of the badge, but also its text with a leading _v_. It was broken down into two separate functions and the text formatting part was moved to `text-formatters`, where it really belongs.
- unit tests were added for these two functions in `color-formatters.spec` and `text-formatters.spec`, using Sazerac.
- as discussed in #1181, the leading _v_ was omitted for _xxxx-yy-zz_ date patterns. Any future exceptions can easily be added to the `ignoredVersionPatterns` pattern.
- the badge colour was previously switched to orange if a hyphen was found in the version string. This didn't seem ideal, instead pattern matching is done to find keywords such as `beta`, `alpha` or `snapshot`. Of course, this list can easily be extended.
- all badges related to versions now use the `versionText` and `versionColor` functions. There are a few rare exceptions, for instance in cases where the data returned by the service's API allows to figure things out without relying on any parsing/pattern matching (eg. `badgeData.colorscheme = prerelease ? 'orange' : 'blue';`, where `prerelease` is determined from an API's response).
This fixes a bug introduced in 076cb14, wherein we discarded tokens received
from other servers, and wherein we could save tokens with invalid
identification.
The bug was raised by Paul Melnikow.
Sazerac is a library for data-driven tests, where a series of tests asserts that the return value of a function matches the expected value. It provides nice syntax for tightening this up.
https://hackernoon.com/sazerac-data-driven-testing-for-javascript-e3408ac29d8c
This converts our tests to use it, and replaces some similar home-grown code.
I fixed one bug I encountered along the way: mikec/sazerac#12.
* Push frontend to production servers at /index.html
Local production builds will use local server instead of img.shields.io, to support local testing
* Restore https://img.shields.io to example URIs
* Add User Defined URL support
* Add test
* eslint fixes
* 100% coverage
* use JSONpath
* update try.html
* Update tests, restore prefix & suffix
* order dependencies alphabetically
* update jsonpath version dependency
* update url structure & move to query strings
* update error handling & remove xml refrences
* fix eslint errors
* update tests
* update dynamic badge generator
* url -> uri & decode uri
Allow an encoded url to be used.
needed for any uri that requires params in the address
* resolve conflicts
* update for new page generation
* check uri is defined
* add query params to `request-handler.js`
* eslint fixes
* add test for no uri specified
* move query params to be local to dynamic badge
* update tests
* dynamic badge gen use same base url as static badge
This piece of work makes sure preference is given to the user defined value if any, by adding missing calls to `getLabel` when the value of `badgeData.text[0]` is reassigned.
- Followup from #1163
- Retire try.html
- Separate build config for dev and production
- Move config for badge examples into the JS build
- Move the prod transform into npm scripts
- In the future this could be handled using a bundler plugin
- make website builds production build as before
- Run the production build in CI to make sure it’s working
- Build the frontend on Heroku
I developed this for #820 to provide the correct cache behavior when a service wants to use custom parameters from the query string.
For safety, only the declared parameters (and the global parameters) are provided to the service. Consequently, failure to declare a parameter results in the parameter not working at all (undesirable, but easy to debug) rather than indeterminate behavior that depends on the cache state (undesirable, but hard to debug).
The quoting style chnaged in b411f08.
This is to fix the production build, in which image links were all broken because they pointed to shields.io instead of img.shields.io.
This pull request sets us up to generate the badge examples dynamically from data and code.
Right now, try.html is still checked in, mostly for the benefit of reading this diff, though it should be removed on the next pass to avoid unnecessary complexity at merge time.
Add simple badge for Jenkins plugins: shows latest version published to Jenkins' repository (fetched from: https://updates.jenkins.io/update-center.actual.json).
Jenkins usually publishes plugin updates one to two times a day, so 4 hours is a reasonable timeout for this large payload.
Close#622
- Add tests to request-handler to prepare for some tweaks to caching for #820
- Clean up code in request-handler: renames, DRY, arrows, imports
- Allow for clean shutdown of `setInterval` code. This requires the ability to cancel autosaving.
- Upgrade to Mocha 4, and clean up so the process exits on its own (see mochajs/mocha#3044)
- Better encapsulate analytics
- `make setup` (i.e. `make`) in the dev tutorial seems an unnecessary step. Badges will load from my local server after a clone, as long as I open try.html.
Add link support to the following badges:
- flat
- flat-square
- plastic
Adjust social badge
- if only 1 link supplied the whole badge will use that link
- only use hover effects if badge contains a link
* Extended usage of the metric validators
* Fixed incorrect Worldpress test data
* Removed usages of Joi.equal for bare string literals
* Switched to proper star formatting and made tests more robust
* Removed debug
- use objects for social badges (excl examples)
- change from <a><img> -> <object>
- use shields.io for the github badge instead of ghbtns.com
- update twitter
This is a rewrite of #1084.
Also touches the implementation of `npm/v` to keep the implementations more consistent with each other.
Clean lint in master.
Closes#723.
This will allow us to create a review app for a pull request. A review app is a transient deploy of Shields with a unique URI. We can use it to interactively test new PRs without needing to run the branch locally.
Review apps would be especially useful, in conjunction with something like Netlify (#960), to test issues affecting SVG badge rendering on different browsers (#1132).
For the review app to be helpful for layout purposes, we're going to need Verdana on the CI machine. The font there is not measuring text correctly.
The Discord API occasionally returns Cloudflare HTML errors or invalid JSON, so in those cases it will fallback to the standard 'inaccessible' message. Some of the returned errors have uppercase letters, so toLowerCase() is used to stay consistent with the rest of shields.
Close#981
Fixes#746Fixes#848
Works by making the font-size `110px` instead of `11px` so the browser doesnt enforce the minimum font size and then scales the text down to 10%.
Also fixes the padding issue on Firefox.
Implements #1113.
Removed extra space in 2 cases (failing tests without this change):
1) Github downloads for latest release
[ GET http://localhost:1111/github/downloads/photonstorm/phaser/latest/total.json ]:
ValidationError: child "value" fails because ["value" with value "63k " fails to match the required pattern: /^[0-9]+[kMGTPEZY]?$/]
--
2) Github downloads-pre for latest release
[ GET http://localhost:1111/github/downloads-pre/photonstorm/phaser/latest/total.json ]:
ValidationError: child "value" fails because ["value" with value "34 " fails to match the required pattern: /^[0-9]+[kMGTPEZY]?$/]
--
3) Github downloads for specific asset from latest release
[ GET http://localhost:1111/github/downloads/atom/atom/latest/atom-amd64.deb.json ]:
ValidationError: child "value" fails because ["value" with value "3k [atom-amd64.deb]" fails to match the required pattern: /^[0-9]+[kMGTPEZY]? \[atom-amd64\.deb\]$/]
--
4) Github downloads-pre for specific asset from latest release
[ GET http://localhost:1111/github/downloads-pre/atom/atom/latest/atom-amd64.deb.json ]:
ValidationError: child "value" fails because ["value" with value "372 [atom-amd64.deb]" fails to match the required pattern: /^[0-9]+[kMGTPEZY]? \[atom-amd64\.deb\]$/]
Also, include `lib/suggest.js` which is part of the server, and rename `vendor` to `service-tests` to match the renames which occurred during the review of #937.
Use the endpoint on img.shields.io added in #1114 to fetch the PR title.
This sidesteps the authentication requirement, and helps with #979 – except for PRs that need to run the Github service tests, which will need a separate solution.
With this patch, the service tests run in a separate Travis job. That makes it easy to see whether a PR failure is resulting from unit tests/lint failures, or service tests, which are inherently flakier.
By running these in a single build stage, they will both run, even if the unit tests + lint fail. This is good, because it's helpful to see the result of a failed integration test, even when there's a lint or unit test failure.
It seems like a mistake from #870. Indeed, the code in that patch
defaults to shields.io for BASE_URL, but the author mentions they
think it defaults to img.shields.io: https://github.com/badges/shields/pull/870#discussion_r115143960
The correct value to maintain the behavior that was present prior
to the patch in question was indeed img.shields.io.
This adds badges for Github issues and pull requests. You can display the state, title, username, number of comments, age, time since last update, and state of checks.
Provides an endpoint the Shields CI can use to fetch PR titles for #979 and resolves#1011.
Because I despise nitpicking stuff like indentation and spacing in pull request comments, I'd like to nudge forward our automated style checking, at least for new files being added.
I don't want to totally rewrite server.js just to get automated style checking… the blame tracking is just too useful. So let's it's just take care of that when we start splitting it out.
More discussion in #948.
The intended behavior of the bracketed [github], [bower], [discord] service names in the pull request title is to trigger the designated service tests. That way, affected services can be proven working during code review, without needing to run tests on a dev machine, nor running all the slow (and flaky) service tests.
Example pull request titles:
- [Travis] Fix timeout issues
- [Travis Sonar] Support user token authentication
- [CRAN CPAN CTAN] Add test coverage
The observed behavior is that, whenever bracketed service names are provided, all of the service tests run.
This is due to a Mocha limitation, which is that exclusive tests (it.only and describe.only) can only be applied synchronously. In other words, if we try to fetch the PR title and then add exclusive tests in the callback, all the tests will run anyway. This is true even when using _mocha --delay, as we are, and is true whether I use request or node-fetch.
Undoubtedly this could be fixed, though it's not worth it. The problem is obscure and therefore low priority for Mocha, which is quite backlogged.
And, there is an easy workaround, which is to generate the list of services to test in a separate process.
The pull request script test:services:pr is now split into two parts. First the :prepare script infers the pull request context, fetches the PR title, and writes the list of affected services to a file. Then the :run script reads the list of affected services and runs the appropriate tests.
In addition to sidestepping the Mocha bug, this setup makes it easier to reason about and debug these two steps of the test runner on a dev machine, and since I can't get pipefail to work – and want to be able to run the steps separately – I'm not using Node's built in pre scripts.
Overall, separating these concerns this makes the test runner easier to reason about.
- Except for social badges, omit logos by default (#983)
- Omit the logo from a social badge using the query string: `?logo=`
(#983)
- Opt in to named logos using the query string: `?logo=appveyor`
- Provide custom logo data as before: `?logo=data:image/png;base64,...`
- Rewrite badge data functions, with unit tests
Unit tests are covering the new code very well, though the underlying
functionality (logos) is untested.
Close#983
- Update 'downloads'->'users' as label,
- added `/u/` as option
- kept `/d/` as an option for backwards compatibility
- moved example from 'Downloads'->'Misc' section
Closes#1016
The original code has been simplified as well, but commented out.
I don't think we need the original code using the issues API, as it has
some limitations (no label support, only up to 30, or 100 issues).
If Verdana.ttf can't be loaded, the font file pointed by the
FALLBACK_FONT_PATH environment variable will be loaded.
This fixes width computation errors that can occur with non-latin
characters when running with Docker.
- use `const` instead of `var` where possible
- use `'` instead of `"` consistently
- replace `forEach` loop with `reduce` call
Thanks to @Daniel15 for review!
* Add template for secret.json
- Move to faster and lighter Alpine base image
* Update documentation
* Update documentation
* Fix Github token config for secret.json
* Extend env file for Docker runtime configuration
- Update documentation
- Add gh_token for GH personal access token to secret template
* Change http to https in infoSite
* Update .dockerignore
* Update .gitignore
* Update dockerignore
* Remove ENV directive from Dockerfile
- Environment is needed at runtime, not at buildtime
* Docker: contain secret.json in private/
- Incorporates fix from 7c8b0e3d
* Use localhost in example env
* Use baseUrl in GitHub redirect
* Move GH personal token retrieval up
- To remove duplicate Promise.then()
* Typo in shields.example.env
According to http://central.sonatype.org/pages/ossrh-guide.html#releasing-to-central:
> Upon release, your component will be published to Central: this typically occurs within 10 minutes, though updates to search can take up to two hours.
So, besides the delay, if the indexing jobs for search.maven.org are paused (see https://issues.sonatype.org/browse/OSSRH-27247), it may take quite some time to see the last artifact version even though it has been actually released on Maven Central.
This uses 'latest' version instead of 'release' version. According to the Maven documentation of the maven-metadata.xml (http://maven.apache.org/ref/3.2.5/maven-repository-metadata/repository-metadata.html):
- 'latest': what the latest version in the directory is, including snapshots;
- 'release': what the latest version in the directory is, of the releases only.
Using the 'release' version would imply altering the behavior of the badge, i.e. getting the release version instead of the latest version, which could also be a snapshot version.
Fixes#846.
According to the [Mozilla documentation about regular expressions](https://developer.mozilla.org/en/docs/Web/JavaScript/Guide/Regular_Expressions), the special character '\w' is equivalent to '[A-Za-z0-9_]', which does not include the hyphen character (i.e. '-'). This cause the matching of services containing a hyphen to fail (e.g. 'maven-central').
Reorg of the tests: move them just alongside their code. The principle relates to grouping by coupling, not by function and is established in best-practice documents (e.g. https://github.com/focusaurus/express_code_structure#underlying-principles-and-motivations), despite its break from the tradition of a separate `test/` tree. All of today's tools can handle tests spread through the repository.
There are some good, if subtle consequences of this change:
- Since files are close at hand, friction is reduced at development time, which encourages that new tests are written to cover new behaviors.
- It's easier to find the tests that cover a particular piece of functionality.
- It's easier to see which code has tests and which doesn't.
- Eliminate manual testing which is error-prone and time consuming, and must be repeated many times through the PR review process
- Make contributing more fun. For many, fixing bugs and making new badges is faster and more satisfying with automated tests than with manual testing.
- Push out the work of testing new badges to a much broader net. The PR originator could write tests, but so could any other contributor who wants to push review along.
- Detect badge failures resulting from changes in vendor contracts without waiting for user reports.
- Detect and prevent regressions in the code.
- Be runnable, readable, writable, and editable by as many developers as possible, including those who may not be familiar with JavaScript test tools.
-- @paulmelnikow, @niccokunzmann, @Daniel15
The website relies on GitHub Pages. When created, that did not support
TLS. However, last year, support for TLS was added, as detailed
in the following blog post:
https://github.com/blog/2186-https-for-github-pages
- Build index.html at deploy time
- Update corresponding documentation references
- Since index.html is untracked, git add needs -f
- Clarify gh-pages generated commit message
- Improve Makefile dependencies related to website generation
As discussed in #936, tracking the index.html causes makes PRs longer / noisier
and causes extra merge conflicts. More importantly, it causes contributors to
inadvertently edit the wrong file, which causes extra work (#949) or
contributions to be lost (#898).
Since there's no need for index.html in development (everything uses try.html) a
logical solution is to generate and commit the index.html at deploy time.
Recording compiled or generated files in a deploy commit is a reasonable
practice for git-based deploys (Heroku, gh-pages, and others).
The old version of this was slightly "unsafe" for my taste, in that it depended
on the local copy of gh-pages (if it existed) and master. The new version just
replaces gh-pages with master + the new commit.
Closes#936.
Fixes#954 (the PR).
While working on some tests, I was having a tricky problem in a test suite. Eventually I tracked it down to an interaction between tests. I suspected the test library, but once I tried to make an isolated test case, I realized the test library was working fine. It turns out it was the server’s request cache. The fix is to clear the cache between tests.
Not needed for this PR, though I’m adding it to this branch because it conflicts with this change.
Running the server in process is necessary for the mock to work. This is an approach I’ve taken in the past. I experimented with this setup quite a bit when I was playing around with a test suite, and it seemed to work well enough. Setting `process.argv` is a admitedly a bit gross, though a cleaner approach would require more involved changes to `server.js`.
Given the chunks coming from imagemagick are getting stored memory and
then tucked into a cache, this function could as easily return a buffer
via callback. Streaming is just making it more complex. (And trickier to
test!)
In ef1a5159, the switch to using imagemagick made a faulty use of the library by
listening for an 'end' event that is never raised. As a result, the cache was
never populated.
In d985f81f, a fix that takes care of the fact that the previously mentioned
dead code relies on a non-existent variable caused it to kill the server when a
raster badge is requested twice, as what it stored in the cache was the pipe
transmitting chunks, not the chunks themselves, and the pipe (a Socket object)
cannot be subsequently sent through a pipe. The following error occured instead:
events.js:163
throw er; // Unhandled 'error' event
^
TypeError: Invalid non-string/buffer chunk
at chunkInvalid (_stream_readable.js:395:10)
at readableAddChunk (_stream_readable.js:150:12)
at DataStream.Readable.push (_stream_readable.js:136:10)
at DataStream._read (/home/m/shields/lib/svg-to-img.js:45:21)
at DataStream.Readable.read (_stream_readable.js:350:10)
at resume_ (_stream_readable.js:739:12)
at _combinedTickCallback (internal/process/next_tick.js:80:11)
at process._tickDomainCallback (internal/process/next_tick.js:128:9)
The OpenAPI Specification (formerly known as the Swagger RESTful API
Documentation Specification) defines a format for describing RESTful
APIs. The Swagger project provides a set of tools for working with this
format, including a hosted validator which provides a validation badge
and JSON result.[1] This commit adds shields.io support for this badge.
The service currently only provides validation of files conforming to
version 2.0 of the OpenAPI Specification. This commit adds a path
component for specifying the version under the assumption that the
validator may support version 3.0 or later as they are released.
It accepts the URL to validate as two path components, a scheme followed
by the rest of the URL, to match the convention used for the JIRA host
and webpage online shields.
Changes in v2:
- Use bitbucket in try.html example for clarity.
- Change /v/ in URL to /valid/ to avoid conflict with v=version.
1. https://github.com/swagger-api/validator-badge
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
The following warning is emitted by Node.js:
> DeprecationWarning: Using Buffer without `new` will soon stop working. Use `new
> Buffer()`, or preferably `Buffer.from()`, `Buffer.allocUnsafe()` or
> `Buffer.alloc()` instead.
This patch removes this warning.
Projects that have '0' technical debt would otherwise receive a
lightgrey badge instead of a brightgreen one.
Signed-off-by: Sebastian Hoß <mail@shoss.de>
The old LRU implementation stored a list's indices to reference items in that
list, but deletions from the list made indices point to the wrong slot.
Functionally, it meant that deleted slots were not guaranteed to be the oldest
slot.
Using a linked list fixes that.
Prior to this patch, time spend in badge.js (computing text width and
compressing the SVG with SVGO) averaged 8.4 ms.
After this patch, it clocks at 2.4 ms on average.
Assuming this is the CPU bottleneck, it means that servers used to only be able
to handle 119 req/s (empirically, it is closer to 100 req/s). It should now
handle 416 req/s (although a better guess is at 1/0.004 = 250 req/s).
- Use metric() for the displayed number
- Use encodeURI() for API parameters
- Explicitly use a condition expression instead of a number where a boolean is expected
Part of #790.
As raised by Adriaan (@agboom), the .github-user-tokens.json file was
incorrectly exposed, causing the risk of users' GitHub tokens to be used
by other entities for the purpose of increasing their rate limits by
pretending to be shields.io.
Mozilla's website uses that format.
Also, show star-rating as "4/5" instead of "4 stars" (which looks verbose, less
informative, and grammatically incorrect if there is a single star).
Add a link to the Linux Foundation Core Infrastructure Initiative (CII)
best practices badge, which uses the shields.io spec.
To see this, visit: https://bestpractices.coreinfrastructure.org/
and select "Projects".
.comment(`This pull request was merged to [{{ pull_request.base.ref }}]({{ repository.html_url }}/tree/{{ pull_request.base.ref }}) branch. This change is now waiting for deployment, which will usually happen within a few days. Stay tuned by joining our \`#ops\` channel on [Discord](https://discordapp.com/invite/HjJCwm5)!
After deployment, changes are copied to [gh-pages]({{ repository.html_url }}/tree/gh-pages) branch: `)
This is the home of Shields.io, home to the badge design specification, API documentation, and server code for Badges as a Service.
Shields is a community project. We invite your participation through
financial contributions, issues, and pull requests!
We invite participation through [GitHub Issues][], which we use much like a discussion forum. This repository should only contain non-implementation specific topics: specifications, design, and the web site.
## Ways you can help
## This implementation
### Financial contributions
Please see [INSTALL.md][] for information on how to start contributing code to
shields.io.
We welcome financial contributions in full transparency on our
[open collective](https://opencollective.com/shields). Anyone can file an
expense. If the expense makes sense for the development of the community, it
will be "merged" into the ledger of our open collective by the core
contributors and the person who filed the expense will be reimbursed.
[INSTALL.md]: ./INSTALL.md
### Contributing code
Note that the root gets redirected to <http://shields.io>.
For testing purposes, you can go to `http://localhost/try.html`.
You should modify that file. The "real" root, `http://localhost/index.html`,
gets generated from the `try.html` file with a `make website`.
This project has quite a backlog of suggestions! If you're new to the project,
maybe you'd like to open a pull request to address one of them:
Whether you integrate it into your editor or not, a pre-commit hook will run
Prettier before a commit by default.
Please report **bugs** and discuss implementation specific concerns (performance characteristics, etc.) in the repository for the respective implementation.
You can build and run the server locally using Docker. First build an image:
```console
$ docker build -t shields ./
Sending build context to Docker daemon 3.923 MB
Step 0 : FROM node:0.12.7-onbuild
…
Removing intermediate container c4678889953f
Successfully built 4471b442c220
```
Then run the container:
```console
$ docker run --rm -p 8080:80 shields
> gh-badges@1.1.2 start /usr/src/app
> node server.js
http://[::1]:80/try.html
```
Assuming Docker is running locally, you should be able to get to the application at http://localhost:8080/try.html. If you run Docker in a virtual machine (such as boot2docker or Docker Machine) then you will need to replace `localhost` with the actual IP address of that virtual machine.
# Main Server Sysadmin
- DNS round-robin between https://vps197850.ovh.net/try.html and https://vps244529.ovh.net/try.html.
- Self-signed TLS certificates, but `img.shields.io` is behind CloudFlare, which provides signed certificates.
- Using node v0.12.7 because later versions, combined with node-canvas, give inaccurate badge measurements.
- Using forever (the node monitor) to automatically restart the server when it crashes.
See https://github.com/badges/ServerScript for helper admin scripts.
# Links
See <https://github.com/h5bp/lazyweb-requests/issues/150> for a story of the
project's inception.
This is also available as a gem `badgerbadgerbadger`, [code here][gem].
Shields has been dedicated to the public domain. It is protected by the Creative Commons CC0 Universal Public Domain Dedication license. You can read the entire license below or at http://creativecommons.org/publicdomain/zero/1.0/deed.en.
# CC0 UNIVERSAL PUBLIC DOMAIN DEDICATION LICENSE
## Statement of Purpose
The laws of most jurisdictions throughout the world automatically confer exclusive Copyright and Related Rights (defined below) upon the creator and subsequent owner(s) (each and all, an "owner") of an original work of authorship and/or a database (each, a "Work").
Certain owners wish to permanently relinquish those rights to a Work for the purpose of contributing to a commons of creative, cultural and scientific works ("Commons") that the public can reliably and without fear of later claims of infringement build upon, modify, incorporate in other works, reuse and redistribute as freely as possible in any form whatsoever and for any purposes, including without limitation commercial purposes. These owners may contribute to the Commons to promote the ideal of a free culture and the further production of creative, cultural and scientific works, or to gain reputation or greater distribution for their Work in part through the use and efforts of others.
For these and/or other purposes and motivations, and without any expectation of additional consideration or compensation, the person associating CC0 with a Work (the "Affirmer"), to the extent that he or she is an owner of Copyright and Related Rights in the Work, voluntarily elects to apply CC0 to the Work and publicly distribute the Work under its terms, with knowledge of his or her Copyright and Related Rights in the Work and the meaning and intended legal effect of CC0 on those rights.
1. Copyright and Related Rights. A Work made available under CC0 may be protected by copyright and related or neighboring rights ("Copyright and Related Rights"). Copyright and Related Rights include, but are not limited to, the following:
a. the right to reproduce, adapt, distribute, perform, display, communicate, and translate a Work;
b. moral rights retained by the original author(s) and/or performer(s);
c. publicity and privacy rights pertaining to a person's image or likeness depicted in a Work;
rights protecting against unfair competition in regards to a Work, subject to the limitations in paragraph 4(a), below;
d. rights protecting the extraction, dissemination, use and reuse of data in a Work;
e. database rights (such as those arising under Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, and under any national implementation thereof, including any amended or successor version of such directive); and
f. other similar, equivalent or corresponding rights throughout the world based on applicable law or treaty, and any national implementations thereof.
2. Waiver. To the greatest extent permitted by, but not in contravention of, applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and unconditionally waives, abandons, and surrenders all of Affirmer's Copyright and Related Rights and associated claims and causes of action, whether now known or unknown (including existing as well as future claims and causes of action), in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each member of the public at large and to the detriment of Affirmer's heirs and successors, fully intending that such Waiver shall not be subject to revocation, rescission, cancellation, termination, or any other legal or equitable action to disrupt the quiet enjoyment of the Work by the public as contemplated by Affirmer's express Statement of Purpose.
3. Public License Fallback. Should any part of the Waiver for any reason be judged legally invalid or ineffective under applicable law, then the Waiver shall be preserved to the maximum extent permitted taking into account Affirmer's express Statement of Purpose. In addition, to the extent the Waiver is so judged Affirmer hereby grants to each affected person a royalty-free, non transferable, non sublicensable, non exclusive, irrevocable and unconditional license to exercise Affirmer's Copyright and Related Rights in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "License"). The License shall be deemed effective as of the date CC0 was applied by Affirmer to the Work. Should any part of the License for any reason be judged legally invalid or ineffective under applicable law, such partial invalidity or ineffectiveness shall not invalidate the remainder of the License, and in such case Affirmer hereby affirms that he or she will not (i) exercise any of his or her remaining Copyright and Related Rights in the Work or (ii) assert any associated claims and causes of action with respect to the Work, in either case contrary to Affirmer's express Statement of Purpose.
4. Limitations and Disclaimers.
a. No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document.
b. Affirmer offers the Work as-is and makes no representations or warranties of any kind concerning the Work, express, implied, statutory or otherwise, including without limitation warranties of title, merchantability, fitness for a particular purpose, non infringement, or the absence of latent or other defects, accuracy, or the present or absence of errors, whether or not discoverable, all to the greatest extent permissible under applicable law.
c. Affirmer disclaims responsibility for clearing rights of other persons that may apply to the Work or any use thereof, including without limitation any person's Copyright and Related Rights in the Work. Further, Affirmer disclaims responsibility for obtaining any necessary consents, permissions or other rights required for any use of the Work.
d. Affirmer understands and acknowledges that Creative Commons is not a party to this document and has no duty or obligation with respect to this CC0 or use of the Work.
<p align="center"><sup><strong>An image server for legible and concise information. Our <a href="http://shields.io/">Homepage</a> | <a href="https://twitter.com/shields_io">Twitter</a></strong></sup></p>
As you can see from the zoomed 400% versions of these badges above, nobody is (really) using the same badge file and at normal size, they're hardly legible. Worst of all, they're completely inconsistent. The information provided isn't of the same kind on each badge. The context is blurry, which doesn't make for a straightforward understanding of how these badges are relevant to the project they're attached to and what information they provide.
## The Shields solution
As you can see below, without increasing the footprint of these badges, I've tried to increase legibility and coherence, removing useless text to decrease the horizontal length in the (likely) scenario that more of these badge thingies crop up on READMEs all across the land.

This badge design corresponds to an old and now deprecated version which has since been replaced by beautiful and scalable SVG versions that can be found on [shields.io](http://shields.io).
- [SemVer](https://semver.org/) version observance: 
-amount of [Liberapay](https://liberapay.com/) donations per week: 
Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [[Become a sponsor](https://opencollective.com/shields#sponsor)]
exports['The badge generator badges with logos should always produce the same badge simple-icons javascript logo custom color (rgba(46,204,113,0.8)) 1']=`
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.