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.

[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 :)

[chriss1245]

Hi @nebuk89, apologies if I come across as persistent, but this feature would be incredibly valuable for us. From my perspective, a notification indicating a workflow was canceled due to a concurrency limit (having in mind that the latest run cancel the prioirs) seem a bit useless to me. In fact, such cases shouldn't even be marked as failures. "skipped" might be more appropriate, but certainly not "failed" cause this behavior is expected from the moment we define the cici workflow.

This kind of situation could push us to explore alternative solutions, which is something we’d prefer to avoid. Could you let us know if this feature request is being prioritized? It’s worth noting that this request isn’t new

—it dates back to 2022.

I have no idea of the implications it has. But I am sure that at GH you will agree with us. Let them know.

Your support on this would mean a lot. Thank you in advance!

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

[saikishor]

+1

[mattglet]

+1

[Firestar99]

+1

[leigh-sesameai]

+1

[wolfgangwalther]

Can we suppress '+1' notifications, too?

[leigh-sesameai]

+1

[codeflorist]

+1

[CyrilFind]

+1, we are a community of notification haters, notifying each other about it

[fitzgibbonjack]

+1

Like others have said, we cancel stale builds (to save resource and prevent deploy errors) where I work and this is causing massive amounts of notifications - it's conditioned me to ignore notification emails.

[chriss1245]

To be honest, I think this matter should be given a high priority. It is a recurrent problem that all of us have.

[ryeleo]

I also would like this for the sake of using the "Require status checks to pass" Ruleset feature with my cancel-in-progress: true workflow.

Require status checks to pass
Choose which status checks must pass before the ref is updated. When enabled, commits must first be pushed to another ref where the checks pass.

Right now, my cancel-in-progress: true workflow always results in the "Require status checks to pass" Ruleset failing. So, I cannot enable it for this workflow in this repository.

Screenshot of the ruleset failing in the pull request:

Screenshot of the ruleset itself:

[chriss1245]

Why this feature which seems so simple to implement and seems so important is not being taken into account?