Open stvnrlly opened 1 year ago
This is dependent on Github actions getting a review to separate and specify the badges we'd like to incorporate.
I spent about a day on this and there are some decisions that need to be made about these badges.
It's really easy to make a badge for a pass/fail GitHub Action. It's basically built into GitHub, you can just drill around in the menu and you can get the markdown for the badge and put in the README. But does this tell us anything useful? We can know that 'checks' passed and 'daily checks' passed and 'drift' failed. Is that enough? Even if we break our GitHub Actions into multiple yml files, is pass/fail enough and what do we want to show?
For the specific case of code coverage, it doesn't seem like we can do it with our current GitHub Action. I tried digging the code coverage number out of our coverage report with JSONPath, and the problem is that we have to write the badge markdown to a local file (call it badge.md) and then import that text into the README. Which means every push will forcibly update the README. Plus it is hard to auto-edit the file that way. I could not find a way to create a static badge that reflected code coverage by relying on our own internal coverage report.
There is a way to make a code coverage badge, of course. And the way I'm familiar with can be seen here: https://github.com/usgs/aqts-capture-trigger/blob/master/README.md
This uses travis and codecov and export all our code coverage numbers to a third party server, which allows us to have a static badge in the README.
I just question if it is worth the refactoring involved to get such a badge.
We can use badges and such to pull out key statuses in a central location in the README to give an at-a-glance view of how things are going.