Specify that an MR must be merged after another MR
- BE weight: 5
- FE weight: 3
Problem to solve
Sometimes we need to create an MR, containing the same code, against both projects. When we do this, it is imperative that the EE MR be merged before the CE MR. This means that, as maintainers, we can't simply "set and forget" the "Merge When Pipeline Succeeds" flag - we have to keep an eye on the EE MR, and manually press the merge button on the CE MR once it merges.
MWPS was used on these two MRs. The CE MR was merged almost 30 minutes earlier than the EE MR, contravening our stated policy. It happened to be fine at this time, with these MRs, but in the future, this could lead to the CE MR being automatically reverted.
One way of solving this is with "super merge requests" - #6424 (closed) / #3427 (closed) - but this is EE-only and, perhaps too big a bite. It also ensures that all MRs go in at the same time, when all we need here is for one MR to go in after another.
Another example would be
gitlab-ce merges where each project should be changed in a certain order, versions incremented and dependencies bumped.
Allow merge requests to be related to each other, so that the order in which they should merge can be described.
Working as a developer, I will be able to:
- open my
- add a link between the two merge requests indicating that the
gitlab-eemerge request must merge before the
If a merge request is ready to merge (including merge when pipeline succeeds), but it is related to an unmerged merge request with the "merge after" attribute, then the merge is prohibited. This will prevent the
gitlab-ce merge request accidentally being merged before the corresponding
gitlab-ee merge request is merged.
The next iteration (TODO) would allow the merge button to be clicked on the
gitlab-ce merge request if the
gitlab-ee merge request is mergeable, triggering the
gitlab-ee merge request then the
gitlab-ce merge request.
This iteration does not support “Merge when pipeline succeeds” (MWPS) if a MR is being blocked by another MR — see reasons.
Users can only specify which MRs block an MR (this MR is blocked by X), and not which MRs are blocked by an MR (this MR blocks X). This can help us simplify the initial approach so it's easier to deal with permissions — the user is free to say that their MR is blocked by X, but they may not have permission to say that their MR blocks X.
|Edit MR||MR widget|
|Re-uses the input from adding related issues (can enter MR URL or ref.) The placeholder is
||This new widget row is only visible if there are currently blocking MRs. Basically, we would only show it if there are any open or closed blocking MRs. The expanded list re-uses the design from gitlab-ce#47007 (closed)|
|If there are blocking MRs that the current user doesn't have access to, we show a
If the current MR is blocked by 1+ MRs, we display the typical
There are items to resolve above… message near the
What does success look like, and how can we measure that?
Merge requests are already highly utilized, but there are many large projects/applications with related repositories where changes regularly span multiple repos. We can measure usage by extending the usage ping to measure how many merge request relationships are created. This should increase as we continue to implement group merge requests further.
Not part of scope: As a GitLab maintainer, I can set MWPS on a CE+EE MR pair and walk away, confident that they will be merged in the right order