GitHub Community
-
|
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. |
Beta Was this translation helpful? Give feedback.
Replies: 11 comments 1 reply
-
|
There is an earlier reported topic about the similar issue: Hi folks, I had a workflow that was always reporting failure state even though it was succeeding. The workflow name AND file name were both the same: build-release-containers. The file had the yml extension, though. Once I changed the workflow name to something more natural, like “Build Releae Containers”, the badge began to properly show the success state. Maybe a bug? 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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Hey there @OKaluza 👋 Pinged our team on this one and discovered that the latest run for the 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 Thanks so much for raising this! 🙇 |
Beta Was this translation helpful? Give feedback.
-
|
I am seeing the same issue with my badge: github.com//github.com/aws/amazon-chime-sdk-js/workflows/CI%20Workflow/badge.svg 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 |
Beta Was this translation helpful? Give feedback.
-
|
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). 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: https://github.com/aws/amazon-chime-sdk-js/workflows/CI%20Workflow/badge.svg?branch=hotfix-script 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. |
Beta Was this translation helpful? Give feedback.
-
|
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 https://github.com/aws/amazon-chime-sdk-js/workflows/CI%20Workflow/badge.svg?event=pull_request, it doesnt show the status of the last time this workflow was triggered by this event, regardless of the branch? |
Beta Was this translation helpful? Give feedback.
-
|
github.com
//github.com/aws/amazon-chime-sdk-js/workflows/CI%20Workflow/badge.svg 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? |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
This is still an issue today @nethgato https://github.com/beeb/remote-wol-rs/actions/workflows/build.yml
|
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
still seeing this
|
Beta Was this translation helpful? Give feedback.
-
Still seeing "failling" besides the green in the workflow and the green tick on commit |
Beta Was this translation helpful? Give feedback.
Hey there @OKaluza 👋
Pinged our team on this one and discovered that the latest run for the
Deployworkflow 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
failingtags 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 long…