Skip to content

Specify that an MR must be merged after another MR

  • BE weight: 5
  • FE weight: 3

Problem to solve

Applications are made from many services, libraries, and components. Although it is best practice for these to be decoupled so that they can change independently of one another through versioning (or some other approach), this isn't always possible. When components are spread over multiple GitLab projects, developers need to be able prevent changes that depend on each other from merging in the wrong order and breaking the CI build.

This is particularly important in large organizations where communication is more difficult and merge order can't simply be coordinated through conversations and norms, and determining why a build is broken could require investigating numerous related projects.

At GitLab, we have two separate projects - https://gitlab.com/gitlab-org/gitlab-ce and https://gitlab.com/gitlab-org/gitlab-ee

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.

Further details

Recent example:

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" - https://gitlab.com/gitlab-org/gitlab-ee/issues/6424 / https://gitlab.com/gitlab-org/gitlab-ee/issues/3427 - 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 gitaly-proto -> gitaly -> gitlab-ce merges where each project should be changed in a certain order, versions incremented and dependencies bumped.

Proposal

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 gitlab-ce and gitlab-ee merge requests
  • add a link between the two merge requests indicating that the gitlab-ee merge request must merge before the gitlab-ce merge request

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 Enter a merge request URL or !reference Example validation errors: badly formatted URLs or lack of permissions to view an MR. 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 https://gitlab.com/gitlab-org/gitlab-ce/issues/47007
image image
If there are blocking MRs that the current user doesn't have access to, we show a X inaccessible merge request(s) token in the input. These inaccessible MRs can be removed by any user.
image

If the current MR is blocked by 1+ MRs, we display the typical There are items to resolve above… message near the Merge button.

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

Tasks

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by 🤖 GitLab Bot 🤖