GitHub Deployment notifications filter

[derwasp]

Currently it's possible to create filtered subscription for a bunch of events, but it's not possible for the deployment events. Since we are deploying quite often, we have way too many notifications and in reality are only looking at the failed ones.

It would be extremely cool if we could filter based on the deployment state, like so: /github subscribe myawesomeorg/MyIncredibleProject deployments +status:failure

Related to #913

[welcome[bot]]

Thanks for opening this issue! If you would like to help implement an improvement, read more about contributing and consider submitting a pull request.

[simonbrandhof]

Filtering by environment is another use-case for this improvement.

[stale[bot]]

Is this still relevant? If so, just comment with any updates and we'll leave it open. Otherwise, if there is no further activity, it will be closed.

[arielkirkwood]

I think it’s still relevant.

[raghera]

I think it's still relevant. We only care about deployments to some envs not all and particularly failures.

[almed4]

Agreed! We don't want to spam our whole org with dev deployments, but it's important for API consumers to know when we do releases :)

[JoaquinFernandez]

Yes, it is a use case for us a well, for notifying only on deployment failure

[fbjork]

+1

[seanconrad1]

+1

[tobiastornros]

+1 for this. Vercel deployments are spamming in our channels...

[earthpyy]

+1 for this!

[danwkennedy]

Another use case: we only want to monitor deployments for a specific branch (ie. main). Right now, every PR that might kick off a build workflow is pushing its status status to our Slack channel.

[tughril]

+1 for this!

[pratikyadav]

+1 for Filtering by environment and state

[kirqz23]

+1 filtering by env and state

[jonathan-dunn-telus]

+1 !!

[seanconrad1]

+1

[jrea]

+1

[TreeOfLearning]

+2

[tubbo]

We use preview deployments for our staging environments, so using /github subscribe deployments is really noisy for us. Ideally, we'd like to filter deployment notifications to only the main branch, so one can see what has been pushed to production.

[dlazares]

+1, any updates on this as a feature?

[styd]

+1

[jamie-unmind]

+1

[mdial89f]

This feature is definitley in our "longed for" column. We deploy environments tracked by GH Environmnets/Deployments from 'n' number of branches, but only want the alerts for a few select branches to avoid alarm fatigue.
I absolutely love the notifications though, and how they auto update as the deployment status changes. Just need filtering and we're all set!

[dstoyanoff]

+1 for env filter

[berryd]

+1

[benjaminpaige]

+1 pretty please

[am-cornelis]

We'd also be using a feature like this, in particular filtering out on the workflow name

[tihuan]

+1 still hoping this get bumped in priority, or if there's any pointers on how to implement this, my team might be able to take a look. Thanks!

[itaispiegel]

+1

[jackblanc]

+1

[jonathan-dunn-telus]

+1 would be really helpful ! Thanks

[Ibrahim-elouard]

+1

[metarsit-coinhako]

+1

[vbalazs]

Please use the reactions to vote up the issue and avoid the unnecessary +1 comments 🙏 They notify all the issue subscribers every time. I always get excited that there is an update about this, just to see that it was an another spammy comment 😿

I don't wish to unsubscribe to this issue since I'm still interested in it.

Since the requirements and popularity here are quite clear, maybe the repo maintainers could consider locking this issue for external comments (and give a much needed update 🙏)

[igor9silva]

4 years in and still no option 🥲

My use case is very simple: I only want to notify for our production environment. Isn't it most people use case? What am I missing?

I tried with workflows instead of deployment, but no option as well.

[styd]

Hey, @igor9silva ! We had almost the same need as you. Only we separate the notifications to different channels in slack, e.g. production to #production-deployment channel and staging to #staging-deployment. We decided to switch to using this action in our workflows instead.

[igor9silva]

Hey, @igor9silva ! We had almost the same need as you. Only we separate the notifications to different channels in slack, e.g. production to #production-deployment channel and staging to #staging-deployment. We decided to switch to using this action in our workflows instead.

Thanks for the reference!

[landsman]

what the hell there is no filter for the environment of deployment?

[opp-svega]

+1

[007vasy]

+1

[RZandvoort-VSM]

+1

[larsjoakimgrahn]

Please do not continue commenting with +1 on this issue. Instead use reactions on the initial post. Writing +1 triggers a notification for every person who is following this issue.

[eliasmistler]

Are there any updates on this? This really seems like a basic feature that lots of people need, and I'm quite surprised nothing has happened in 4 years :/

[igor9silva]

They're to worried with Copilot

[eliasmistler]

Actually, looking at the docs, there is a new way to do this:

Don't use the deployments notifications:

/github unsubscribe my-org/my-repo deployments

Instead, use the worfklows feature:

/github subscribe my-org/my-repo workflows:{name:“deploy_to_prod”}

That being said, I couldn't get it to work yet -- if someone does get it to work, please share!

[psilore]

I got the subscription workflow to work, but in tandem with releases subscription

Kinda like this,

/github subscribe organisation/repository releases, workflows:{ name:"Production" event:"release" }

If I understand this correctly, this works because I have a workflow name: Production and it triggers on the event release

Example (removed org in screenshot):

However, I dont like that theres a button "Re-run all jobs" because if I send that to a slack channel just to inform, members in that channel can unintentionally and intentionally trigger workflow =( Dont know how to bypass that or remove button