Trigger a new pipeline after each increasing pipeline tier transition

From Draft to Ready

• The MR description does not contain any TODO:s
• !2840 (merged) is merged
• !2840 (merged) was tested in the playground project
  • ✅ See https://gitlab.com/gitlab-org/quality/engineering-productivity/triage-ops-playground/-/merge_requests/14
• Feedback from !2840 (comment 1940374441) is implemented
• We change the target for this MR to master
• We changed 4 hours to 8 hours in the processor message
• Split the automation bot logic in two methods is merged
• The communication was reviewed and approved

Context

Closes #1539 (closed)

• The NewPipelineOnApproval processor adds the pipeline:mr-approved label, AND triggers a new pipeline the first time this label is added. It is used on:
  • https://gitlab.com/gitlab-org/gitlab
  • https://gitlab.com/gitlab-org/terraform-provider-gitlab
  • NOT used on https://gitlab.com/gitlab-org/security/gitlab
• The MrApprovedLabel processor adds the pipeline:mr-approved label as soon as an MR is approved by at least one person. It is used on:
  • https://gitlab.com/gitlab-org/gitlab
  • https://gitlab.com/gitlab-org/security/gitlab

Note: The MrApprovedLabel processor will not remove the pipeline:mr-approved if the approvals are being removed (behavior changed with !2837 (merged))

Requirements

1. The gitlab terraform provider project should still work as it used to
2. We still need to add the pipeline:mr-approved label once the MR is “first” approved for BOTH canonical and security

• Why? pipeline:mr-approved is the label that we use to add a lot of jobs to the "post-approved" CI/CD pipelines.

Chosen solution

• Keep the NewPipelineOnApproval processor, but ensure it's only used for the terraform-provider-gitlab project (requirement 1 ✅, done in this MR)
• Keep the MrApprovedLabel processor, even though it will be redundant with PipelineTierTransitions. We'll be able to remove it once this MR is merged.
• Introduce a new Processor: PipelineTierTransitions (done in !2840 (merged))
• Replace the PipelineTierLabel processor with the PipelineTierTransitions processor (this MR)

We now will apply the pipeline:mr-approved label with the PipelineTierTransitions processor, as it also runs on gitlab-org/gitlab and gitlab-org/security/gitlab (requirement 2 ✅ )

What does this MR do?

Looking at it commit-by-commit:

• Move processor to a subfolder: Move the NewPipelineOnApproval processor to a subfolder called gitlab_terraform_provider, and only run this processor against the GitLab project of the same name
• Move PipelineTierTransitions processor away from sandbox: Promote the PipelineTierTransitions processor away from the sandbox to be applied on canonical and security projects.
• Remove the PipelineTierLabel processor: We introduced the PipelineTierTransitions processor in !2840 (merged), and it is replacing PipelineTierLabel (PipelineTierTransitions = PipelineTierLabel + "trigger new pipelines" + "write discussion on pipeline tiers").
• Two other commits for a small performance improvement and a follow-up refactoring.

Expected impact & dry-runs

• The message we sent when an MR is first approved will change.
• For MRs created by team members and some automations, we'll trigger a new pipeline every time we increase tiers.

Action items

• If adding environment variables for reactive processors, update config/triage-web.yaml and .gitlab/ci/triage-web.yml
• (If applicable) Add documentation to the handbook pages for Triage Operations =>
• (If applicable) Identify the affected groups and how to communicate to them:
  • /cc @person_or_group =>
  • Relevant Slack channels => #development, #backend-maintainers, #frontend
  • Engineering week-in-review

Communication

With !2838 (merged), we're changing the automation message that you received when first approving a merge request.

The message will now be talking about pipeline tiers, and what the last reviewer needs to check before the MR is set to auto-merge.

Additionally, we'll trigger a new merge request pipeline not only after the first approval, but for every pipeline tiers increase (e.g. from tier 2 to tier 3).

Please leave your thoughts in the pipeline tiers feedback issue.