Automate security backports that cherry-pick cleanly to previous stable branches

I think there's potential to dramatically reduce developer toil while creating security fixes.

Currently a developer opens an MR against master, it goes through review, and then the developer creates backports for the previous stable branches.

We currently require manual backports because it's not a guarantee that a fix for master will apply cleanly to a stable branch due to code changes. But I'd suspect that some, or even most, can.1

Here's what I'd propose:

  1. For security MRs targeting master, trigger a release-tools pipeline that checks if the merge commit2 can be cherry-picked to previous stable branches.
    • NOTE: This would require support for a cherry-pick "dry-run", which doesn't currently exist. Options for that are outlined below.
  2. If it applies cleanly, add the Pick into X.Y label; if it doesn't, inform the author that a backport is required.
  3. During the security release process, where we merge backports, also perform cherry-picking.

One major potential sticking point is what to do when we said a backport would pick cleanly, but at release time that's no longer true -- likely due to cascading changes from other fixes -- and we need manual intervention.

Cherry-pick dry-runs

Git has no native support for "dry-run" cherry-picks, nor has GitLab built that functionality. gitlab-org/gitaly!2382 (merged) adds support for this to Gitaly, and will need support added to GitLab.

  1. I think we can automate verifying this. For every master MR, check its backports and see if the diff is exactly the same. ↩

  2. This depends on being able to merge the master MR as soon as it's ready since we need a merge commit to test against; see &109 (closed) ↩

Edited by Robert Speicher