Can we suppress 'Run cancelled' notifications?

[alec-maxoptra]

We would like to be able to suppress 'Run cancelled' notifications but still receive 'Run failed' notifications.

We have a 'cancel-in-progress: true' workflow triggered on push which builds a set of markdown files into HTML, and a team of copy-editors who push to this repository using a WYSIWYG editor.

This process results in many small commits to the repository, and so we get spammed by the 'Run cancelled' notifications.

Is there any way we can cancel a run without triggering a notification?

[ethomson]

Thanks for the feedback @alec-maxoptra - there's not at the moment, I'm afraid. I think that there's an opportunity for us to improve our notifications, and we'll take your feedback into account when we look at that work. I'll make sure that this is on the backlog.

Appreciate you taking the time.

[corneil]

Being able to use gh cli to prevent notifications when cancelling would be very useful. We have a housekeeping job that where we want to check frequently but only perform actions after a set of conditions are met one of them is based on time of last success of housekeeping. So cancelling the housekeeping run is the best way to distinguish.
Thus if we can use the gh cli to present notifications before we use gh cli to cancel the run would resuce noise

[szamanr]

@ethomson any update on this? is it something that's being considered in the near future?

[szamanr]

@ethomson bump. it's been 1.5 years and we have almost 200 people upvoting this.

[jsoref]

He's no longer with GitHub

[szamanr]

then who do we ping to get this done? 😄

[Th3S4mur41]

This would be especially interesting for repositories using semantic-release where you definitely want to avoid multiple runs or a release workflow in parallel.
We make sure to avoid conflict by using cancel-workflow-action but there is an unnecessary spam of canceled workflow notifications resulting out of this process.

[jsoref]

You can probably use a merge queue these days to avoid some of these problems.

(That said, I really want the feature described here...)

[sanity]

Just to add, I'm also getting frustrated by this. It's generating a lot of notification false positives which is teaching me to ignore notifications :-/

[tshakah]

Yeah, I'm starting to do this as well

[mrclrchtr]

In our team, stale runs are always canceled. This results in a massive number of notifications. I would be very happy if this could be changed.

[szamanr]

same as ☝️, my inbox is constantly bombarded with these notifications. i have to manually select all and mark as done when that happens. it's cumbersome, and has led to me missing a notification among the noise at least a few times.

[ImanMahmoudinasab]

We have some checkers that re-run when developers push new commits to the branch of the pr. It doesn't make sense for in-progress workflows to continue, instead, we cancel them and re-run the checkers for the latest changes.

Ideally, I expect it was possible to do something like:

name: My workflow

on:
  pull_request

concurrency:
  group: ${{ github.workflow }}-PR${{ github.event.pull_request.number }}
  cancel-in-progress: true
  notify-if-canceled: false # this is not a real config please do not copy past it :)

[rostislav-simonik]

the feature is still desired, but if you use gmail, just create a filter to archive/delete the email to avoid notifications.

[biodranik]

Legitimate canceling by explicit concurrency section in the action should not generate email notifications, or at least should be configurable.

Please fix it to motivate developers cancel unnecessary jobs and have more free Github runners for everyone.

[yairasco]

Is this feature request under development? I see many developers with the same issue receiving bunch of cancelled workflow notifications in email.. pretty annoying!

[szamanr]

our use case is we're using graphite (go check it out, it's awesome) to support stacked PRs. it uses rebase to keep branches in sync, which means every time i update the stack with code from the main branch, it force pushes each branch in the stack.

for reasons i don't entirely understand, this always produces a lot of cancelled runs, i suppose it has to do with rebasing. the end result is that every time i sync, my github notifications inbox is spammed with countless messages and i have to manually select them all and mark as done. easy to miss real notifications this way.

[jsoref]

Not that what you're doing shouldn't work, but, have you looked into using a merge queue?

I'd be interested in knowing if it addresses your needs.

[j-mie6]

I'd also love this, my CI is now set up to cancel runs on old commits when new commits are pushed, and this results in a lot of redundant emails.

[flagrant99]

This is driving me crazy. The work flow being cancelled is NORMAL. Multiple Devs check in before build is finished. It Cancels the build because some code changed. Why do we need an alert for this? This is not an error.

[gexcube]

+1

[szamanr]

it's driving me crazy as well. is there another channel where we can report this, or should we accept that this will likely never get picked up?

[chrisdp]

Would also love a way to prevent emails for canceled work flows.

[SashaGoldin]

Canceled workflows should not send a failure email. It leads to a ton of false negatives, and ignoring possibly legitimate failure emails with github actions.

[smorimoto]

+1

[szamanr]

@thispaul me and at least almost 200 other people are frustrated by this for over 1.5 years now. i see you're a PM at github, could you update us on whether the team is aware of this issue? or point me to a person i can contact.

to everyone who got an annoying notification because of this message: sorry. but i bet it's not as annoying as a constant stream of daily useless notifications from cancelled runs. in fact, i would urge anyone who reads this to reply in order to keep the discussion on the first page, and find and ping other members of github until this gets noticed.

[codeflorist]

I hereby formally reply.

This is a bug, that has very annoying effects for a lot of people.

A fix would be greatly appreciated.

[thispaul]

Thanks @szamanr for reaching out. I have shared your feedback with the team working on Actions

[RSS1102]

@thispaul

I am very presumptuous to inquire about your progress again.🙏🙏
It has been stacked for a long time and I don't know how long it will continue.
There are many states here, and I hope he can set them in CI to correctly inform developers of the current state... I think this is important for action users.

[pauldraper]

@thispaul interesting...what was their reaction?

[evrenucar]

Cancelled workflow ≠ Failed workflow

please prioritize this issue thanks ^^

[iwiznia]

I agree on this being annoying and not useful in lots of cases, so having a way to disable it would be nice

[mkevins]

Please consider prioritizing a fix for this.

[DennyWeinberg]

+1

[epiqu1n]

+1, getting spammed with "run cancelled" emails because I pushed a change while tests are running is rather annoying.

[JasonLovesDoggo]

+1

[dbleier]

+1

[ReneWerner87]

+1

[knubonrk]

Can you give an example of how this would be done to avoid getting a notification for cancelled actions? The downvotes you are getting is an indication that a lot of people have tried and could not find a way to do this.

[matejdro]

This smells a lot like an AI answer to me.

[queenofcorgis]

@berthablea

We’ve clarified our stance on using generative AI tools like ChatGPT within our Community via this announcement. Please review the guidelines to ensure your post meets them as failure to adhere to those rules can result in action taken by our moderator team.  You can read our updated Code of Conduct and the announcement for more details. Thank you for helping us maintain an authentic and beneficial space for everyone.

[JHWelch]

I just realized that the emails even fire when you MANUALLY cancel the workflow, not just if it was from a cancel-in-progress in the YML.

I do not need an email for an action I just manually undertook, it would be great if we could see some movement on this. It is really hard for me to notice any actual failures amongst all the cancelled ones.

[antoniozzo]

+1

[willbush]

We ended up removing a concurrency group in nixpkgs which runs on every PR due to notifications to contributors which I initially added to save wasted resources.