cca46b7e94
- 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). |
||
|---|---|---|
| doc | ||
| lib | ||
| logo | ||
| public | ||
| spec | ||
| templates | ||
| test | ||
| .buildpacks | ||
| .dockerignore | ||
| .editorconfig | ||
| .eslintrc.yml | ||
| .gitignore | ||
| .travis.yml | ||
| CNAME | ||
| CONTRIBUTING.md | ||
| coverage.svg | ||
| Dockerfile | ||
| favicon.png | ||
| gh-badge.js | ||
| INSTALL.md | ||
| LICENSE.md | ||
| logo.svg | ||
| Makefile | ||
| package.json | ||
| README.md | ||
| server.js | ||
| try.html | ||
An image server for legible and concise information. Our Homepage | Twitter
- INSTALL – installation instructions.
- CONTRIBUTING – project contribution guidelines.
- SPECIFICATION – spec for the visual design of Shields badges.
- LICENSE – public domain dedication.
Make your own badges here! (Quick guide: https://img.shields.io/badge/left-right-f39f37.svg.)
Solving the problem
Many GitHub repositories sport badges for things like:
| Travis CI (build status) |
 |
| Gemnasium (dependency checks) |
 |
| Code Climate (static analysis) |
 |
| RubyGems (released gem version) |
 |
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.
Examples
What kind of metadata can you convey using badges?
- test build status:
build | failing - code coverage percentage:
coverage | 80% - stable release version:
version | 1.2.3 - package manager release:
gem | 1.2.3 - status of third-party dependencies:
dependencies | out-of-date - static code analysis GPA:
code climate | 3.8 - SemVer version observance:
semver | 2.0.0 - amount of Gratipay donations per week:
tips | $2/week
Services using the Shields standard
- Badger
- badges2svg
- CII Best Practices
- Codacy
- Code Climate
- Coveralls
- docs.rs
- Forkability
- Gemnasium
- GoDoc
- PHPPackages
- Read the Docs
- reposs
- ruby-gem-downloads-badge
- Scrutinizer
- Semaphore
- Travis CI
- Version Badge
- VersionEye
Legal
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.