73fcc1ccac
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 is home to Shields.io, a service for concise, consistent, and legible badges in SVG and raster format, which can easily be included in GitHub readmes or any other web page. The service supports dozens of continuous integration services, package registries, distributions, app stores, social networks, code coverage services, and code analysis services. Every month it serves over 470 million images.
This repo hosts:
- The Shields.io frontend and server code
- An NPM library for generating badges
- The badge design specification
Examples
- code coverage percentage:
- stable release version:
- package manager release:
- status of third-party dependencies:
- static code analysis grade:
- SemVer version observance:
- amount of Liberapay donations per week:
- Python package downloads:
- Chrome Web Store extension rating:
- Uptime Robot percentage:
Make your own badges!
(Quick example: https://img.shields.io/badge/left-right-f39f37.svg)
Browse a complete list of badges.
Contributing
Shields is a community project. We invite your participation through issues and pull requests! You can peruse the contributing guidelines.
When adding or changing a service please add tests.
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:
You can read a tutorial on how to add a badge.
Development
- Install Node 8 or later. You can use the package manager of your choice. Tests need to pass in Node 8 and 9.
- Clone this repository.
- Run
npm installto install the dependencies. - Run
npm run buildto build the frontend. - Run
npm startto start the server. - Open
http://[::]:8080/to view the home page.
To generate the frontend using production cache settings – that is,
badge preview URIs with maxAge – run LONG_CACHE=true npm run build.
To analyze the frontend bundle, run npm install webpack-bundle-analyzer and
then ANALYZE=true npm start.
Snapshot tests ensure we don't inadvertently make changes that affect the
SVG or JSON output. When deliberately changing the output, run
SNAPSHOT_DRY=1 npm run test:js:server to preview changes to the saved
snapshots, and SNAPSHOT_UPDATE=1 npm run test:js:server to update them.
The server can be configured to use Sentry (configuration) and Prometheus (configuration).
Daily tests, including a full run of the service tests and overall code coverage, are run via badges/daily-tests.
Hosting your own server
There is documentation about hosting your own server.
History
b.adge.me was the original website for this service. Heroku back then had a thing which made it hard to use a toplevel domain with it, hence the odd domain. It used code developed in 2013 from a library called gh-badges, both developed by Thaddée Tyl. The project merged with shields.io by making it use the b.adge.me code and closed b.adge.me.
The original badge specification was developed in 2013 by Olivier Lacan. It was inspired by the Travis CI and similar badges (there were a lot fewer, back then). In 2014 Thaddée Tyl redesigned it with help from a Travis CI employee and convinced everyone to switch to it. The old design is what today is called the plastic style; the new one is the flat style.
You can read more about the project's inception, the motivation of the SVG badge specification, and the specification itself.
Project leaders
espadrine is the sysadmin.
These contributors donate time on a consistent basis to help guide and maintain the project:
Related projects
License
All assets and code are under the CC0 LICENSE and in the public domain unless specified otherwise.
The assets in logo/ are trademarks of their respective companies and are
under their terms and license.
Contributors
This project exists thanks to all the people who contribute. [Contribute].
Backers
Thank you to all our backers! 🙏 [Become a backer]
Sponsors
Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [Become a sponsor]
