Skip to content

Modify the way release-tools processes security merge requests

After, we discovered security MR's targeting master can be merged as soon as they're ready. We need to modify our tooling to allow such change.

FYI: Most of the implementation details were taken care of on https://gitlab.com/gitlab-org/release-tools/-/issues/471, but they're under a feature flag.

Proposal

  • Enable Pipelines for merged results - #1107 (closed)
  • Merge requests targeting master are merged during the 23rd to the 28th
    • They're only merged if they're ready to be processed
    • They're merged by triggering a new pipeline
    • Only MRs associated to GitLab and Omnibus are considered on this phase.
  • Backports, and MRs associated to other GitLab subcomponents ( Gitaly, Pages, etc) are merged during the Security Release
    • They're merged immediately (without triggering a new pipeline)

To do

Technical debt

Testing

Setup

Scenario A: merging master - #1122 (comment 418220733)

  • Execute /chatops run release merge --dry-run --security --master command. #1122 (comment 418220733)
    • Ensure that MRs associated to GitLab and Omnibus security issues are processed
    • Ensure that MR associated with Gitaly is not processed

Scenario B: Merging backports and remaining merge requests - #1122 (comment 418242862)

  • Create a new implementation issue - https://gitlab.com/gitlab-org/security/gitlab/-/issues/258
  • Associate any merged merge request targeting master
  • Associate the backports
  • Ensure new implementation issue is valid
  • Associate this implementation issue to the fake security release tracking issue
  • Execute /chatops run release merge --dry-run --security command. Ensure:
    • Backports and Gitaly MR's are processed

Questions

  • During the 23rd to 28th window, should we only merge MR associated to GitLab project, what about MRs for the rest of the GitLab ecosystem components (Omnibus, Gitaly, Pages)?
    • Only for GitLab and Omnibus project, rest of the MRs will be merged during the Security Release
  • Should we still pick MRs targeting master into the auto-deploy branch? Given these are created every 6h, they will be included in the next auto-deploy branch.
    • Auto-deploy branches scheduled was modified from 6h to 8h. For the first iteration, let's not pick them into the auto-deploy branch.

Follow ups

Edited by Mayra Cabrera