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.

[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.

[apoulet-olo]

+1

[manickavela29]

Another attempt of request!

[burningtnt]

Please we do need this feature with concurrency key. :(

[marijoo]

+1

Notifications for manual cancellations are equally useless and disturbing like the ones sent for cancellations due to concurrency settings. A configurable option would be very welcome.

[LeoTheGriff]

+1

[chase]

At the very least can we get a system option for this?

Something like:

---

• Only notify for failed workloads
  • Including cancelled workloads

---

[nebuk89]

Hey y'all :) this is great feedback, and sorry for the silence. We are currently doing a review of a bunch of these long-standing paper-cuts (I know we have a bunch of these kinda 2020 age issues that Ed/Chris have responded to!). Our hope is over the next 6-9 months we can start to burn some of these down. I will ensure this one is on the list, but cannot guarantee where it ends in the stack rank :) hopefully you will start to see some of these moving soon though <3

[chriss1245]

Hi, is there any updates on this matter?

[nebuk89]

Nothing yet :( I am still going across all the amazing feedback y'all have all given us on many of these :D and we have quite a backlog. We have our first paper cut fixes coming out soon, and will then line up our next round. <3 stick with us, it's quite the backlog you have given us :)

[grav]

Here's a simple script that will go and mark all "workflow run cancelled" notifications as "Done":

https://gist.github.com/grav/d82fb04b5f4f945c1dc9e86361d49010

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐