The main purpose of webhooks is to allow external systems to be notified of projects Quality Gate status.
- The external system needs to be notified when a new analysis is done in order to check the QG status that results from the analysis.
- The external system needs to be notified when an update through the UI changes the QG status to possibly allow/trigger actions depending on the QG status is green or red.
With the support of short-lived branch and the dynamic update of the QG status when issues are edited in the UI, Webhooks calls can now be triggered when 2 different types of events happen:
- A new project analysis is done (regardless of the status of the background task or of the quality gate)
- An issue type, severity or status is updated and the QG status changes.
- An issue is flagged as WF and the status of the short lived branch turns green
- The severity of an issue is increased and the QG status of the long lived branch turns red
Currently, when an issue is updated, a webhook call is made even if the QG status doesn't change.
Ex: When the severity of an issue is updated in a short living branch
When an issue is edited, webhook calls should be triggered only when the QG status changes.
Consequence: If the metrics that are part of the QG conditions change but the QG remains the same, webhook calls are not triggered.
Webhook documentation in SQ settings and Online documentation should be completed to not restrict trigger event to project analysis.