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?

[chriss1245]

I dont know, a lot of time has passed.... I am starting to loose faith.

[chrisdp]

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

[pschuette22]

Still an issue

[Yeshey]

+1

[WentTheFox]

Let me preface this by saying that yes, it does suck that this is not an option built into the platform and it's quite wasteful for GitHub to be sending emails for things people do not want to receive e-mails about. However, it likely does not trigger their threshold for "we should do something about this" until it becomes too costly and I wouldn't expect the likely negligible amount of "run cancelled" e-mails to even register on the books for a company the scale and size of GitHub.

Instead of piling on with yet another +1 in a discussion where the chances for a real decision-maker at the company looking is fairly slim, I would encourage anyone looking for the ability to configure this to use existing filtering/rules already built in to their e-mail service of choice. Most of the popular hosted e-mail solutions offer some functionality like this in some way, shape, or form, where you can tell the server what to do with the message so your primary inbox becomes less cluttered.

Below is my setup for ProtonMail, which gets these mails out of my sight and subsequently results in unthinkable amounts of reclaimed productivity*

Filtering setup

Conditions

• if the sender is exactly notifications@github.com
• and the subject contains Run cancelled

Actions

• move to the Archive folder
• mark the message as Read

|

^{*I am aware this isn't an option for everyone, and your use case might be so specific that this will not help, but it's sure as heck better for the majority of people than waiting indefinitely for a fix from the platform itself}

[erezcor]

+1

[Aycarambo]

+1

[munoztd0]

+1

[KRRT7]

+1

[cprivitere]

Forget the email notifications, how do I get the push notifications to stop?

[rosstex]

+1

[smolkaj]

+1

[viniciusd]

It doesn't look like this LLM-generated comment adds anything to the discussion

[codeflorist]

Has this ever been a "discussion"? Feels more like a wailing wall made of corporate concrete indifference. This AI post adds an even more Kafkaesk touch to it. It was probably trained from posts of this thread - by the conpany, that ignores us - to wholeheartedly support our issue. Strange Days. 🤷

[atharva049]

No. In GitHub Actions you cannot suppress only “Run cancelled” notifications while keeping “Run failed” notifications. GitHub notifications don’t allow filtering by run status.

[chriss1245]

Just vive code It guys. It's no so hard

[geramirez]

Hey folks! Notifications team here. We have handled this issue. "Run Cancelled" notifications have been suppressed when Only notify for failed workflows is selected. They will appear when this option is unselected.

[alec-maxoptra]

@geramirez Thank you for your timely help on this!