Allow more fine grained configuration of webhooks
Problem to solve
Currently, Webhook triggers can be enabled for specific objects (examples: issues, confidential issues, merge requests). However, these objects sometimes have different types of discreet events happen to them, and there's currently no simple way to listen to a subset of those events.
Further details
I'll give an example. Merge Request hooks are triggered on different events: 'open', 'approved', etc. Those come through in the payload body. However, you may not be interested in listening to all events for all use cases—for example, if a webhook is being used to trigger an external build job, approval actions may be irrelevant.
Proposal
Allow a more granular selection of webhook events. By default, users would be able to subscribe to all events for an object, as it is currently. However, an additional set of checkboxes could be provided with the relevant events under each object type to select or deselect a subset of desired events to listen to.
UI ideas in #17898 (comment 1387878382) and #17898 (comment 1389679208)
What does success look like, and how can we measure that?
Users would be able to navigate to the integrations settings, or webhook settings, and be presented with a more granular selection under each webhook object based on the presently available event types for each object. Upon selecting, users would be able to listen to all events within a specified object or a subset of the available events.
See original description
We can add webhooks for a list of defined events.https://docs.gitlab.com/ce/user/project/integrations/webhooks.html
Sometimes, we may only care about one specific property returned by that event. For example, if we want to post all Frontend gitlab-ce3630472 issues to a Slack channel, we only care about the label of any issue being updated. We don't care if the assignee changes, for example. Without being able to know whether just the label changed or not, you would have to have your own persistence layer of some kind to check if you already posted an issue before sending it to slack.
My proposal is to add checkboxes under each of these event types to allow you to finely control what the event will be fired for.
Using the example above, we could create a new Issue events webhook, that unselects every property apart from label. Then, that event will only fire when the label of an issue updates.
However, we still have the problem that an issue labeled Frontend gitlab-ce3630472 gitlab-ce~2278655 that is then relabelled to Frontend gitlab-ce3630472 ~Build would still be posted to slack twice. Therefore, we would also need a Unique only option that would only fire the event if that resource hasn't already been sent previously. I moved this proposal to a new issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/31489
Maybe this is all too much and its actually down to the consumer to have a persistence layer if they want this level of configuration?
/shrug
Interested Customers
Use Cases
- Only trigger a issue event web hook when an issue with a specific label is created or an existing issue with that label is updated, closed, or reopened.