Introduce auto-deploy patches through MRs rather than committing to the default branch of Tissue

Summary

Note

This is an output from the discussion at https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/20685#note_2935420276

We have two methods for adding patches: opening an MR to Tissue (used by team members, Renovate bot, some ringctl commands such as ringctl patch delete) or committing directly to the default branch of Tissue (used by release/tools through the ringctl upgrade command)

The existence of two methods is a problem because when solving problems such as https://gitlab.com/gitlab-com/gl-infra/delivery/-/work_items/20685+, we need to implement two separate methods for the two methods of patch addition.

  1. When patches are added using MRs, we can rely on GitLab's deployments widget - implemented in this Tissue MR
  2. When patches are added directly, the deployments widget is not usable. So, we have to post comments on the specific commits which added patches - Not implemented yet

We anticipate such issues to continue in the future as well. For instance, when rolling back / reverting a patch, we can not assume that a patch will always have an MR associated with it. So, we can not post comments on the original MR which introduced the patch, in order to let its authors know that their patch was reverted.

Proposed solution

Merge requests to Tissue should be the only way to introduce patches into the patch queue

This will be a medium-large change in terms of implementation. But it will provide a simple interface to team members who are looking for why a particular patch was introduced. Currently, the knowledge about auto-deploy patches being added without MRs is well-known within grouprelease-and-deploy in GitLab.com / GitLab Infrastructure Team / GitLab Tenant Scale / Cells Infrastructure team / Cells Infrastructure team issues but not outside.

Possible drawbacks

Too many MRs

There will be at least 10 MRs every day from auto-deploy. This will accumulate to about ~3000 MRs per year. Additionally, there will also be an MR for each package which is promoted from ring 0 to ring 1

Populated MR list view

The list of MRs will be populated by MRs which are created by the bot. (This is already an issue to some extent because the Renovate bot creates a lot of MRs!)

This is a known limitation, which we can work around by applying appropriate labels on bot-created MRs.

Exit criteria

  • Discuss any objections to the proposed solution
  • Implement the proposed solution OR create issues for implementation
  • Ensure that none of the ringctl commands attempt to commit directly to the default branch of Tissue
  • Branch protection rules to prevent adding commits to the default branch of Tissue, except by the Tissue deployment coordinator bot (The bot that adds commits such as Patch <ULID> is in ring 0, Patch <ULID> is now failed in ring 1, etc.)
Edited by Siddharth Kannan