Make Integration/Webhook Triggers More Finely Grained
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Proposal
Make Integration/Webhook Triggers More Finely Grained
Many of the Integration/Webhook triggers are compound:
- Issue Trigger is triggered on issue created/updated/closed
- Confidential Issue is triggered on issue created/updated/closed
- Merge Request is triggered on merge request created/updated/merged
- Wiki Page is triggered on wiki page created/updated
While there are cases where teams might want to be notified on all Issue or MR changes, there are times where a team might only want one of those events to trigger the webhook.
Our specific usecase is that we want to know when an MR is created, not when it's updated or merged (or any other event); we want to have a low-volume channel that developers can watch to see MRs flow into the system so they can take a look at them if they so choose.
The additional noise from MR updates and MR merges means the team misses the signal of MR creation events.
I would suggest instead of compound triggers as listed above, triggers should look more like:
- Issue Created Trigger
- Issue Updated Trigger
- Issue Closed Trigger
- Confidential Issue Created Trigger
- Confidential Issue Updated Trigger
- Confidential Issue Closed Trigger
- Merge Request Created Trigger
- Merge Request Updated Trigger
- Merge Request Merged Trigger
- Wiki Page Created Trigger
- Wiki Page Updated Trigger
Success
Success looks like improvements to the Integration and Webhook configuration options and triggers whereby GitLab users could modify the Integration/Webhook Settings to trigger only on an MR creation event (or Issue closed event, etc...).