[GitHubChecksStatus] Add commit check badge

[itsvs]

Related to #4364. Adds a badge for Github's commit status endpoint (not quite the same as the check-run endpoints, but similar idea).

[shields-ci]

	Messages
📖	✨ Thanks for your contribution to Shields, @itsvs!

Generated by 🚫 dangerJS against 662b7a3

[lgtm-com]

This pull request introduces 1 alert when merging 7e4ce81 into 91b108d - view on LGTM.com

new alerts:

• 1 for Unused variable, import, function or class

[calebcartwright]

Thank you for the PR @itsvs. Could you please elaborate on the perceived use case for this badge?

I suppose there's technically a brief window where the status will be unknown/dynamic but this largely becomes a static badge very quickly and I don't quite understand the utility of having a commit hash specific status badge.

Typically the build status-type badges are used to dynamically reflect the current status of project/repository/etc. that changes regularly over time, and the same holds true for the check runs data discussed in #4364. However, the status for a single commit doesn't feel like it really fits into that mold

[itsvs]

Hey @calebcartwright, thanks for taking the time to look over my PR!

I agree that there's little use for a commit-specific badge, but Github's commit status endpoint actually allows for the ref to be a hash, branch, or tag (in the latter two cases it uses the head of the ref, which can change often). The motivation behind this badge is largely similar to that of check-run or CI, but it's for projects that use custom CI and therefore don't have badges available. For example, I'm involved in a couple of projects where we use custom buildservers that report build statuses to Github this way. I was hoping to add a badge to their respective documentations that shows whether the latest commit to master built successfully.

Hope this makes sense!

[calebcartwright]

Thanks for the additional context, that's most helpful! In that case I think we'll want to pare back the commit-centric focus to be more explicit that any old ref will suffice. I'd suggest potentially updating the route, the internals like the class and file name, as well as examples that demonstrate non-specific commit uses (e.g. branch). We'd also want to have some non-commit hash tests too.

[itsvs]

Makes sense, I'll make those changes later today. Thanks for the input!

[calebcartwright]

Thanks again for the PR @itsvs! Looks to be in fairly good order overall, and have left some inline feedback for your review. It may seem like a lot of comments, but it's largely just places where Shields has some utils/helpers that should be reused instead of duplicating the functionality those cover 👍

[calebcartwright]

This value will likely need to be tweaked to account for changes in the service test for the 404 scenario

[itsvs]

I believe that resolves all your comments, @calebcartwright!

[calebcartwright]

Excellent, thank you!