GitHub Actions | Listing workflows cancelled by concurrency settings as failed could be misleading

[GabrielCousin]

Hi!

We noticed concurrency settings were introduced lately in GitHub actions and we gave them a try. However, we chose not to use them at the moment for the following reason:

As shown in the below screenshot, the penultimate commit is listed as failed (because its workflow was canceled by the last one)
The cancel feature is working as expected but the team considered it was misleading to see a red cross on it (if you click for more details, you can finally understand it was canceled though).

We don't know if an option can be introduced not to consider these as failed or maybe introducing another icon.

Thanks a bunch!

[lars-reimann]

I'd like this as well. Something like an optional property treat-cancellation-as with values success and failure (default) under concurrency and jobs.<job_id>.concurrency would be great.

Generally, there is some mismatch between the symbols in the commit history for all checks taken together and the symbols for individual checks:

In the history there are symbols for

• Success
• Failure
• Pending

For a single check there are symbols for

• Success
• Failure
• Pending
• Cancelled
• Skipped

In the history a skip has the same effect as a success, while cancellation has the same effect as a failure. The true result is not immediately obvious without clicking on the commit. There should maybe be additional symbols shown in the commit history to denote

• some jobs were skipped, the rest was successful
• some jobs were cancelled, the rest was sucessful or skipped

[ethomson]

Thanks @GabrielCousin - I can see how this could be confusing. I'll take a look at how we can improve this.

[rodo-r2r]

We're seeing the same issue after adding concurrency to our CI.
It would be great if we could treat this as not being an error.

[rocklan]

I'm seeing this as well, it would be great if it could be improved.

[clong-]

We're seeing this too. I think that if workflows are designed around this feature, then the designer is probably acknowledging that cancellation is an acceptable state, hence should not necessarily be treated as failure. It would be great to see a configurable option to dictate whether cancellation yields a failure state or is ignored.

[idejanovic]

One option would be to have another option than the cancel-in-progress like:

concurrency:
  group: "..."
  skip-in-progress: true

[max-sixty]

This also causes badges in the repo to list the build as failing, e.g. in PRQL, after a PR was merged while a previous workflow was running on main:

Is there any workaround for this specific instance of the issue? e.g. has anyone tried making an if expression which generates something unique on the main branch?

[sanity]

Experiencing this same problem, anyone have a workaround?

[goodsign]

Any news on that? Because of this, most of the builds in our CI are now red and the team is getting used to the fact that red CI is normal and usual.

[leahy268]

As above we have the same problem. Multiple Teams deploying and we have PreProd and Prod environments that require approval, We then have these set to "cancel-in-progress: true". This is deliberate as without that pending deployments will just eventually timeout. We only want the latest deployment to be going into Prod and PreProd so the cancel-in-progress true achieves this beautifullly.

However all of these deployments then appear as failed when everything was successful except that we chose not to let a deployment go through to prod.

[torokati44]

+1

[mpushki]

+1

[gustavovalverde]

Hopefully someone at GitHub is looking at this as the Developer Experience is annoying with all thoses ❌'s, making the team used to see those as an "expected outcome", and makes other things very confusing, like notifications on our main branch when something fails —as those are not actual failures, but gets reported as one—.

[Mine02C4]

+1

[mpushki]

I use this name for group

concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref && github.ref || github.run_id }}
  cancel-in-progress: true

[davinchia]

Still no solution for this? We are a big open source repo and are also running into this problem.

[psyinf]

I'm frustrated by this, too. There is no obvious way how to change how the check-summary is evaluated (e.g. not getting "Some checks were not successful" and the red cross in the summary view.
This needs to be either an explicit per-repo configuration option (treat_canceled_as_success) or an option within the jobs
For me the issue arises due to having a two jobs in the pipeline for pushes on feature-branches and updates to PRs which don't need to be performed both in case there is a PR.

[dep]

Need a solution for this too.

[bmson]

Second on this issue. The visual indication of failed tests is affected by intentionally canceled workflows showing up as failed.

Canceled workflows should have a different indicator

[gabe-mercury]

+1

[Gabriella439]

Our company open sourced a GitHub action you can use to work around this problem:

https://github.com/MercuryTechnologies/delete-cancelled-runs

… but it would be really nice if there were a GitHub-native solution to this problem. This GitHub action of ours is more of a hack than a proper solution.

[IOrlandoni]

+1