Feature Request: parameter for tag or commit for Github Action Workflow badge

[jtmoon79]

tl;dr allowing a tag and/or commit parameter for Github Action Workflow badge would allow old documentation to be more accurate

Problem 1 - mistaken passing status

A Github Action Workflow badge always and only shows the last build status for a branch.
https://img.shields.io/github/actions/workflow/status/jtmoon79/super-speedy-syslog-searcher/rust.yml?branch=main
renders

When I look at old commits or tags on Github for which that the Github Action Workflow failed then the badge still reports green build | passing.
For example,
commit 99c27c6c failed to build. Yet the badge embedded in the README.md shows it passed (as of the time of this writing) because it only shows the latest status for the branch main.
And when I look at the next commit fd4434e the same badge status, despite that commit sitting between two failed Github Action Workflow runs.

Problem 2 - mistaken failed status

When I push a commit that fails a Github Action Workflow run, the badge URL reports build | failed. When I browse to old versions of my project on crates.io those old versions report the same build | failed.
So for example, if I were to cause a failed Github Action Workflow run in branch main then this old crates.io release would misleadingly show build | failed badge.

Solution (Feature Request)

It would be great if all build badges, like the Github Action Workflow badge, would allow either or both parameter options of commit and/or tag corresponding to git commits and tags, and this in turn would retrieve the corresponding Github Action Workflow run result. Then all older documentation would retrieve a more correct badge.

So for example, for release 0.2.48 (which has an associated git tag 0.2.48), the badge URL would be
https://img.shields.io/github/actions/workflow/status/jtmoon79/super-speedy-syslog-searcher/rust.yml?branch=main&tag=0.2.48.
Then that release 0.2.48, when browsed via Github or via crates.io, would always show the correct corresponding Github Action Workflow result.

I suspect the tag parameter would be easier for developers to use since they can set the parameter value before committing, among other advantages of tags versus commit hashes (in other words, developers don't know the commit hash until something has been committed).
Something to consider might also be a release tag that would lookup Github Action Workflow status "keying" from a Github Release.

This feature request could apply to all badges that retrieve build status. But for sake of planning and tracking, this Issue only focuses on Github Action Workflows.

[chris48s]

We're quite limited on what we can do with the Github Action Workflow badge. We did try an API-based implementation, but after hitting some issues, we changed it so it is basically just a "scraper" for GitHub's own badge that enables the shields formatting options. When it comes to variants we can only wrap what GitHub exposes, which does not include status for a tag/commit.

There's more background reading on this at

• Github workflow badge showing failure when is not the case #8733
• Github Actions Workflow badge not working for "branchless" push #8736
• switch [GithubActionsWorkflowStatus] to SVG scraper #8738

I can see the reasons why this could be useful, but we are not able to query the data we'd need to implement it.