make Webhook content and format adjustable per event

WHAT IS A WEBHOOK

Sending webhooks is a feature which relays information to pre-defined urls. This allows third party interfaces to get notified of events happening within gitlab, for example in development, security and release processes. They are especially useful in combination with chat, monitoring and project management tools

CURRENT STATE OF IMPLEMENTATION

  1. In the current gitlab implementation, you can choose from a list which events to receive per webhook. For example to only receive notifications when a push to the repository occurs. But you can only specify further conditions just for certain events - for example "only notify on broken pipelines" for the pipeline event (this one seems actually to only be available in the slack integration webhooks) or a regex/wildcard for branches on push events.

  2. The information provided in the actual hook is very basic and not modifiable, containg mostly just a change/creation notification. Depending on the event, there may also be a success / failure message.

  3. The payload format is also not adjustable.

PROPOSED CHANGES

  1. Make the event selection more customizable. The exact conditions available for each event should be open for discussion for everybody. My specified proposals is listed in my use case.

  2. Allow additional information to be attached to webhooks. The extend of this should also be open to discussion. My specified proposals is listed in my use case.

  3. Add a templating / parsing solution to allow individualization of webhooks for further processing.

IMPACT

Currently, the only way to process gitlab webhooks is to send them to an intermediate server and filter and parse them there before further relaying this. This intermediary layer could be dropped by making the webhook system a little more flexible and would greatly add to gitlab being the single point of all DevOps Processes, as i think is the gitlab strategy.

Speficially:

  1. This will grant the ability to generate more specific webhooks. For example, notifications on test environment deployments or test stage pipelines could be separated from production ones on gitlab level and being relayed to different webhook endpoints for processing.

  2. There may be cases in which additional information for an event is needed, but can only be accessed if one has actual access to the affected repository. This is inconvenient on the one hand, and in some cases users may not be able to get acccess to the repository but still need information which could be provided automatically (for example for privately hosted repositories or whatever reason a developer doesn't want to open his code).

  3. There may be situations, especially in middle to big sized companies, in which the JSON data has to have a certain format for processing or has to be adjusted to a layout, for example for direct displaying it in chat applications such as slack in a way following an internal standard.

MY USE CASE

So, this is how currently my deployment process looks like notification-wise: image

As you can see, i activated the "Tag push" and "Deployment" events for the slack integration. I activated the pipeline event notification as well, but only for broken pipelines.

What i would very much appreciate is if i could choose to add the release notes to a "tag push" event, if a relaese is attached.

Also the deployment events should not only contain the last commit, but the option to send the last n commit messages. The deployments should also contain the tag they were triggered by as they not necessarily connected to the tag notification received earlier. This can get confusing when several projects push into the same channel. Also i would like to choose to send the actual Job Name with a deployment and not just the environment. I have environments consisting of multiple jobs being processed in different stages for a deployment.

Furthermore, in accordance with 1), i would like to create separate hooks for different environments.

Last but not least, i have to present certain information, especially regarding deployments, in certain formats to other people which is currently done using an intermediary server of which i would very much like to get rid off.

I'm looking forward to a discussion about my proposal,

Jan

Edited by Jan-Eric Staffel