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:
- 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.
- If it applies cleanly, add the
Pick into X.Y
label; if it doesn't, inform the author that a backport is required. - 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.
-
I think we can automate verifying this. For every
master
MR, check its backports and see if the diff is exactly the same.↩ -
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)↩