Allow for security merge requests to trigger Pipelines for Merged Results
A follow-up of #1018 (closed)
Triggering Pipelines for merged results is required practice when it comes to merging MRs on the GitLab Canonical repositories. These pipelines allow us to execute the current test suite no matter if the merge request is behind master
by X
commits.
To allow for security merge requests to be merged as soon as they don't break master
by executing the latest test suite, we can use "Pipelines for merged results"
Investigation
- To enable Pipelines for Merged Results, we only need to enable the setting on the Security project https://gitlab.com/gitlab-org/security/gitlab/edit
- Enabling Pipelines for merged results will enable merge-train, this one can be disabled using a feature flag
- These two features may be split in upcoming releases gitlab-org/gitlab#244831 (closed)
- Merge-train may not fit the Security Release process for two reasons:
- It triggers pipelines when processing merge requests. This implies that it'll trigger numerous pipelines when processing the backports (e.g 87 pipelines in the last security release). Triggering pipelines on backports is not necessary, since those branches don't have a lot of traffic. Currently, there's no way to disable merge-train on specific branches.
- If there's a failure (legit or flaky) on the merge request pipeline, the merge-train will drop it without any notification.
- Pipelines for Merged Results fits our Security Release process:
- They'll execute CI based on the latest commit on
master
. Currently, we don't have any guarantee that a security MR won't break Securitymaster
once it's merged. - Approvals on MRs are reset when pushing a change, which puts a burden on developers + maintainers. Enabling this setting could help alleviate that burden.
- They'll execute CI based on the latest commit on
Proposal
- Enable Pipelines for merged results on GitLab Security and Omnibus GitLab Security
- Disable merge-train by turning on the feature flag
- When merging MRs targeting
master
our tooling should trigger a pipeline and set MWPS - Backports are merged immediately (without triggering a pipeline)
To do
-
Investigate what is needed to enable Pipelines for merged results on GitLab Security project - #1107 (closed) -
Implement trigger a pipeline when merging merge requests targeting master
and setting MWPS - gitlab-org/release-tools!1181 (merged) -
Complete testing -
Permanently, enable merged results pipelines for GitLab and Omnibus GitLab - #1107 (comment 418152268)
Testing
-
Create two security issues -
Create a fake Security Release Tracking issue and associate the fake implementation issues -
Make one security issue valid, and one invalid -
Enable Merged result pipelines on Security project -
Disable merge-train with through ChatOps -
Enable feature flag on Ops - https://ops.gitlab.net/gitlab-org/release/tools/-/feature_flags/180/edit -
Trigger /chatops run release merge --dry-run --security --master
to ensure it's using the fake Security Release Tracking Issue - #1107 (comment 416821924) -
Execute /chatops run release merge --security --master
and ensure MWPS was set for the MR targetingmaster
Edited by Mayra Cabrera