I don't want to subscribe a slack channel to all issues on arbitrary third party repositories, just to the particular issues on which my team/organization is involved (contributing to / impacted by), so the usual github integration command /github subscribe thirdparty/arbitraryrepo issues does not suffice as it would cause a ton of unwanted noise in the channel. (and the existing label filtering would not cut it)
(Update: there is an open feature request for that https://github.com/integrations/slack/issues/1280)
I neither want to forward my personal github subscriptions to the slack channel as there are lots of projects I am individually involved that have nothing to do with my team's work. (e.g. my direct mentions)
Also, subscription should stay despite I leaved the team/company.
A per-issue public RSS/Atom feed would cut it but it does not exist.
Am I missing something obvious?
As far as I know there is nothing that would suit your need completely at this moment, but have you considered labels?
#1 option You could use filtering based on label which seems to be the closest:
issues, pulls, commits, releases, deployments that has a given label. Syntax example:/github subscribe repo-owner/repo-name +label:"team-a"
team-aNote: a workaround to get info about label change in PR: to convert PR to a draft and back (https://github.com/integrations/slack/issues/965#issuecomment-1330884166)
#2 option Another thing that might be considered is that the account that is used within GitHub Slack app for connecting to Git server will be actually notified also about all its mentions, assignments & reviews! So if you don't use your personal account, you could get generated some related notifications to the whole team / other specific user etc.
EDIT:
Workaround steps to achieve partially what you want (but it can be in some conflict with your Slack / GitHub settings that I’m not aware of):
Caveat: But as we discuss, there’s no simple way to achieve your goal completely. To at least get closer to something similar to what you describe and require, you’d need to accept some compromises and extra steps for workaround as it’s unfortunately not currently natively supported. 3rd hypothetical way is to create even more complex mechanisms of filtering & redirecting data which would increase a level of complexity + you'd also need to maintain it (unless you'd already have something similar existing in your infrastructure) and I wouldn't recommend it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With