Failing badge status for passing runs and filters not working correctly

Hi, anyone know why this status badge is showing “Failing”?

When the associated workflow is passing: here

Notice passing status of most recent actions.

Another issue I notice: runs are also appearing incorrectly at the above linked workflow from different workflows, set filter is “Deploy” but is also showing runs from the “OSMesa” workflow.

1 Like


There is an earlier reported topic about the similar issue:

Sometimes, we also encounter the same problem. After waiting a moment and refresh (or reopen) the web page, the status badge generally can correctly show the latest status.

1 Like

Thanks for the response @brightran. I did give it a while and a few refreshes, but I think it is a deeper problem because the badge is still showing “Failing”, and it’s a couple of days since the action passed now.

Hey there @OKaluza :wave:

Pinged our team on this one and discovered that the latest run for the Deploy workflow on the default branch was cancelled, which is why the badge is showing as failed.

However, as @brightran mentioned, there are some other threads that show evidence of similar behavior under different circumstances. While this particular thread has an answer, I want to make mention of some efforts going on internally, here.

There is refresh work happening that should help with erroneous failing tags being added to successful runs. There is no ETA that I can provide on this effort, and it specifically wouldn’t solve the problem here, but it should make that inadvertent tagging no longer a problem, once completed.

Thanks so much for raising this! :bow:

1 Like

I am seeing the same issue with my badge:

I wanted to know why it shows failing, even though the last run of the CI Workflow is passing. Actions · aws/amazon-chime-sdk-js · GitHub

What I didn’t understand was the badge shows the status of the master branch only, my workflow was running on release in tagged branches, but the badge was displaying the status of the action when run on the master branch (which was some old failed test run).
I fixed it by specifying the branch with ?branch=releasetag in the badge url, of course unfortunately the badge url needs to be updated with every release.

It looks like the same thing with your repo, if you look at the master branch the status is failing, so the badge is correct: Actions · aws/amazon-chime-sdk-js · GitHub if you specify the name of the most recent passing branch from a pull request it shows passing:

It would actually be really useful to have a badge that reported the status of the last run of a particular action, regardless of branch, or a way to specify a wildcard branch.

So it defaults to using master branch, that I understand. Then why can’t I use this option? Adding a workflow status badge - GitHub Docs

For my understanding, my workflow is triggered from a ‘pull_request’, but how come if I do, it doesnt show the status of the last time this workflow was triggered by this event, regardless of the branch?

It seems when using the event filter, it still insists on a specific branch, defaulting to master. Because the pull request happens in a branch, it doesn’t show unless you explicitly add the branch filter.

Again, I think it makes sense to be able to specify “any” or “*” as a branch, or even better and more intuitive: default to no branch filter at all and only behave the way it does now when a branch parameter is used. @nethgato any chance of this making it to the devs? Is it worth posting it somewhere else as a feature request?

Having the Branch filter be able to use “*” would fit this use case. I’m not sure why it isnt included already, as having a CI workflow means that the CI workflow would run on the remote branch that submits the PR. The name of the remote branch created for the purpose of the PR cannot be known beforehand, so how could I use the remote branch as part of this query parameter?

There should be a way to show the status of ALL RUNS of an arbitrary Github Actions workflow, not just the runs that occur in a specified branch, right? @nethgato