search

Squarespace / pgbedrock

Manage a Postgres cluster's roles, role memberships, schema ownership, and privileges
https://pgbedrock.readthedocs.io/en/latest/
Other
311 stars 35 forks source link

Add badges to pgbedrock #34

Closed zcmarine closed 6 years ago

zcmarine commented 6 years ago

Overview People often use badges as a quick way to assess the quality / functionality of a project. After coming across a project this weekend that had a build: failing badge I realized how useful it would be for us to have some quick info at the top of the github README: build status, code coverage, supported Python versions, and supported Postgres versions. This PR adds those elements.

II would encourage reviewing by stepping through the commits because there are some things like renaming a file or changing indentation that make it look like there's a lot more changes than there really are.

Details The badges use hard-coded URLs to get their statuses, which seems to be a limitation of the badging system from what I have read. As a result, if you look at this branch's README it will say coverage: unknown because it's pointing at master and coverage has never occurred on master before. With that said, I've swapped out the references on a different commit and verified that things work. The end result should look like this:

screen shot 2018-05-28 at 2 05 51 pm

Feedback I Want Nothing particular. The most suspect change is how I got coveralls to work by copying the source code to a path that matches the docker container. If one of you know a better way to do this that'd be great, but I spent a half a day fiddling with a bunch of things and this was the best way I got it to work.

I'm also curious what the best order for the badges is. I'd like to highlight the high code coverage and the supported Postgres versions, but aesthetically I also like keeping similar colored badges together. At the moment I'm leaning toward: Travis build state, Coverage, Postgres Versions, Python Versions, which is the order that is in the code in this PR (so slightly different than the image above).

zcmarine commented 6 years ago

Remaining steps for this PR:

  1. Wait for PR #35, which adds support for Postgres 10, to be merged into master.
  2. Rebase this PR off master.
  3. Modify this PR's Postgres badge to reflect Postgres 10 support.
  4. Merge this PR into master.