With this change we expand notification events in GitLab for Slack app. Now you can trigger notifications for group mentions in issue and merge request descriptions, comments on issues, merge requests, and commits.
Reduces team member time overlap in ping responses
Reduces time other teams spend being blocked by or waiting for a response
(for AppSec) Our current implementation is prone to breaking and is only accessible/fixable by a Senior Manager
Which team is requesting this?
AppSec specifically, although other teams would certainly benefit from it. @agroleau mentioned that this might even be a feature for the product itself.
What is your definition of done?
@-mentions for our group showing up in the #sec-appsec Slack channel
@mushakov@arturoherrero This seems to be in your wheelhouse? (TL;DR The AppSec team would like to be notified on Slack whenever their group is @-mentioned anywhere on GitLab.com.)
The Security Automation team has recently started looking into implementing this. It seems like this could be related, but not quite an extension of the Slack notifications we already have for project-level events. In addition to Slack, supporting other chat services in the future might make sense.
Do you have any guidance for us on how to proceed here?
@agroleau Looks like there's going to be a complete rewrite of the Slack integration (i.e. Removal of Slack Notifications Integration). Maybe we should think about an external automation focused on the AppSec use case, to solve their problem until the above epic gets implemented?
@.luke The AppSec request needs a group-wide notification (channel webhook, not DMs), because they would like to coordinate the response to @-mentions on GitLab.com.
@agroleau and I talked about this some more, and thought it might make sense to add this Group mentioned notification type to the existing Slack integration, so it can become part of the new design at some point in the future. WDYT?
@adietrich Apologies for the delayed response on my end. I was looking into this and it's an interesting request. We've been focused on surfacing notifications from key events within the product to Slack Channels and DMs, but haven't explored too deeply how we might hook into the Group / Project notifications (Preferences > Notifications).
I can see the value and have heard requests from customers to be able to essentially choose Slack as the notification option for notifications instead of email. I wonder if as an MVC we could start by defining a Group Webhook for groups/projects. This could be more generic for use in many systems and could give us the means to add it as an option to multiple chat integrations possibly
From there it's possible to enable webhooks in Slack a bit more manually as a starting point, but we could work on bringing it into the Slack integration itself in the future.
Thinking out loud, though. I would want more feedback from @arturoherrero and @.luke on this (cc @Andysoiron as Luke is ). @mushakov may also have thoughts on the impact to GitLab notifications generally.
@g.hickman Thanks for your input! I like the idea of treating this in a more generic way, i.e. a project being mentioned might be as interesting for some users as a group being mentioned.
@arturoherrero I think the handle to track would be the group or project path where the new notification type of i.e. Mentioned is activated. My understanding of the existing integration is that the channel to notify is implicitly configured by the Slack webhook URL, but custom channels would be cool too.
I have implemented this (prototypically for comments) in this MR, but it does present a few usability issues (see this comment).
Would love some thoughts from the Integrations team on whether implementing this as yet-another-event-type (temporarily) seems feasible, we should go an entirely separate route, or this should wait for the full rewrite of the Slack integration.
"Group <Group name with link> was mentioned in a <Comment with link> in project <Project name with link>"
when a group is mentioned in a comment.
What are your thoughts?
or this should wait for the full rewrite of the Slack integration
It should be okay to go ahead and do this before we finish &8670 (closed) as we're going to support all of the existing notification functionality initially at least.
@adietrich Hmm, a few questions that come to mind immediately:
How does a user specify the channel(s) they want group mentions to send to?
Could a group send notifications to multiple different channels or would it require only one channel?
Would this be enabled by default or is there a way to toggle the feature on/off?
There is the question Luke shared in the MR about public vs private projects and what we could/should expose in Slack channels.
Is this prototype working for you locally / within our Dev app? It may help to do a quick walkthrough video to see how this is working for you and consider any implications.
Otherwise, this does seem like a useful addition and great to see your team taking it up!
The current (WIP) MR uses the Slack webhook URL from the Integrations settings. The text field for custom channels exists, but is not used yet.
That's probably up to our implementation (see above).
The default for Mention events is off.
That's a very good point! I suppose a checkbox for i.e. Public projects only would be useful.
Right now it's working in my GDK. I can try to record a walkthrough video.
If we go forward with this particular approach, I will definitely need some help to address the usability issues I mentioned in the MR (and which hopefully will be visible in the walkthrough video soon).
You cannot override the default channel (chosen by the user who installed your app), username, or icon when you're using Incoming Webhooks to post messages.
So these settings apparently no longer work.
Edits:
It looks like the custom channel list is passed to the channel parameter of the slack-notifier for the existing event types, but this no longer works, at least in my test setup.
For #4, it looks like the usual approach is to implement a separate Confidential event version, i.e. Issue and Confidential issue.
Thanks for the responses @adietrich. I'll reserve any further feedback for the video you are working towards, but sounds like all is on track! If there's anything specific I can help with, let me know.
@ankelly Slack notifications that are configured at the group level are currently inherited by all subgroups. If we implement the new Mention event type consistent with that, arbitrary subgroups of gitlab-com/gl-security/appsec would also generate Slack notifications by default, when @-mentioned. You would be able to disable this for individual subgroups, though. Would that work for you?
@ankelly This is finally getting close to being merged, and we'll hopefully be able to test the notifications on a couple of GitLab projects soon.
Just to be safe: the current implementation covers @-mentions of a group in issue descriptions, merge request descriptions, and comments in issues or merge requests. Does this address your use case, or is AppSec being @-mentioned in other contexts often?
Also: while this feature is behind a feature flag, we need to individually enable it on projects that can generate the new Slack notifications. Can you list a handful of projects where you are getting mentioned most often?
Thank you @adietrich! Wow, thank you for all the time and effort that you've put in here!
the current implementation covers @-mentions of a group in issue descriptions, merge request descriptions, and comments in issues or merge requests. Does this address your use case, or is AppSec being @-mentioned in other contexts often?
Yes, this addresses our use case. I wonder about the new OKR work_item issues, do those get covered? (here's an example). How about epics?
while this feature is behind a feature flag, we need to individually enable it on projects that can generate the new Slack notifications
Some projects that we should enable for the feature flag testing:
Note this is not an exhaustive list, so it can only be for testing the new functionality. We need to keep the original automation on for team members to do triage. We can't move over to this for triage yet, especially because of the way SIRT incidents work (new projects that get spun up each time) -- just in case the appsec team gets pinged on one.
Some short-term options while this testing is happening:
Have these new @-mention pings go to a specific separate channel? That way the testing doesn't disrupt the teams workflow but we can still make sure it works.
Modify James' original automation to ignore the projects we manually add for this feature flag time.
Enable this with the limited set of projects, disable James' automation, and ask team members to work out of their GitLab todos
Number 1 is the least disruptive to the teams' workflow, but we wont really be doing anything with the pings while the feature is behind a feature flag
Number 2 seems ideal, but it would require modifying James' automation
Number 3 is just okay, but has a higher likelyhood of something falling through the cracks.
Longer term, @gitlab-com/gl-security/appsec-leadership when this gets fully rolled out to all projects, just to be safe we should maybe move James' original automation to a separate channel and spend a few weeks comparing the pings. That way we can identify any edge cases that popped up.
Are we able to enable the notifications on groups? Or only to project? Asking because we typically have several projects where we do collaborate, for example on gl-security, but this is the same for gitlab-org, etc.
I wonder about the new OKR work_item issues, do those get covered? (here's an example). How about epics?
@ankelly Not yet, I actually had to build in a check for work items during development, because something about them was breaking the notifications. With "epics", are you referring to descriptions of epics? I can work on both when the current state has been merged and is being tested behind the feature flag, but I would really like to get something merged and deployed first.
Some short-term options while this testing is happening:
I think Number 1 sounds like a good first step for testing. It could be combined with Number 2, once you decide the notifications work for you.
Are we able to enable the notifications on groups? Or only to project?
@vdesousa The feature flag needs to be enabled in two places:
The groups that are supposed to receive the new notifications. (Probably just the AppSec group initially.)
The projects that are supposed to generate the new notifications. (Andrew's list of projects.)
When the feature flag is removed, no special configuration will be necessary for projects to generate the notifications.
If you are unsure about the correct group, please do not leave the issue without a group label, and refer to
GitLab's shared responsibility functionality guidelines
for more information on how to triage this kind of issue.
@ankelly Good news, the feature is now (partially) enabled on Production!
I've created a private Slack channel called sec-appsec-mentions and integrated it with the AppSec GitLab group. (The channel is private because I enabled private group mentions in the integration settings, but we can change that, if it's not necessary.)
The notifications are initially enabled for a few projects:
gitlab-com/gl-security/appsec/appsec-team
gitlab-com/gl-security/security-department-meta
Please check if/how this feature works for you, more projects should be enabled soon, and eventually all of them.
@ankelly (and others) do you have any feedback about the feature in its current state? Since we merged with a limited set of notification sources (issue and MR descriptions and comments), are there other sources you would like to have added (urgently)?
Hi @adietrich. I don't have any feedback at this time. I'm planning on spreading awareness about this to the AppSec team tomorrow (2023-08-01) and will ask them to provide you with any feedback.
Repositories that would be helpful to have coverage for sooner (not really urgently, though):
I will put some more thought into this, I don't want to overload you with more to add and I admittedly don't know what limitations we're up against. @adietrich when requesting more sources be added, is there anything we should be considering (other than our own need here)?
@ankelly Sorry, "sources" was referring to @-mention locations other than issue and MR descriptions/comments.
For example, you previously mentioned work items. If that's a location you're getting mentioned a lot, implementing support for those would probably be very valuable.
I'll pass along the additional set of projects, though.
@adietrich Oops, sorry I didn't read your previous comment thoroughly enough. Thanks for clarifying.
As of right now, the work items are the only thing I can think of. We don't get mentioned on them all that often, though -- so I'd say its a "nice to have" with no urgency for being added.
@adietrich we might get mentioned in "tasks". We don't get pinged there a ton so no urgency but SIRT uses tasks quite a lot for their incidents so it could happen.
@ankelly@dcouture Thank you! Sounds like we could implement the additional notification sources in a future iteration, and potentially complete the rollout of the feature in its current state.
Thank you @.luke, that was under my radar.
@adietrich well done! I'll open this issue shortly to create a release blog post and then close it again. I'll tag you on the blog post MR.
I see you've added docs, thanks a lot!
I wanted to implement support for this in IntegrationDiscord, but the settings UI was not working properly. Then I noticed that it is even broken for the Slack notifications integration with an almost up-to-date master and it is even on .com broken.
It shows up in the settings like this (the two checkboxes without any text are the mentions):
Any idea why this is happening and how it can be fixed, so I can implement support for IntegrationDiscord for this notification type?