Skip to content

Only notify active stable branch version failures

What does this MR do and why?

We are working to extend the maintenance policy for patch releases from one version to the last three versions.

In doing so, we added slack notifications anytime a stable branch has a merge commit pipeline that fails (see gitlab-com/gl-infra/delivery#2775 (closed)). The problem is, we will receive a slack notification for any stable branch failures, but we really only want to see these notifications if the branch is one of the versions active in the maintenance policy (the last three versions).

We explored if we could dynamically determine these versions in the CI rules, but it turns out that is not currently feasible. So for now we will just have the three versions hardcoded. Each month, the release managers will update these values so the correct versions are always targeted (see release-tools!2160 (merged) where the release manager process is being updated to include this step).

In this MR, we create the initial rule that targets the last three versions (the currently active versions in the extended maintenance policy): 15-6-stable-ee, 15-7-stable-ee, 15-8-stable-ee. This rule includes the environment variables needed to trigger the slack notification. We also keep the original rule to always run a pipeline on all other stable branch merge commits, but without the slack notification variables.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to gitlab-com/gl-infra/delivery#2823

Edited by Steve Abrams

Merge request reports