Merge request contention is a consequence of approaches that seek determinism, either by: - requiring fast-forward merges (includes semi-linear), or - running tests on the merge commit before adding to master. This is because determinism requires known ordering, and non-instantaneous tasks (rebase and tests) will result in contention. The essential property of all these approaches is that the CI status on the target branch can be known to be the same as on the feature branch, because it is identical to a commit that has already been tested. ### Further details **Scenario: fast-forward/semi-linear merge** – when this merge strategy is enabled, only fast forward merges are permitted. Every time the target branch changes, the merge request must be rebased before it can be fast forward merged. This creates a contention problem where merge requests are continually being rebased and tests re-run competing with others to merge. **Scenario: merge request pipelines** – merge request pipelines will test the merge ref (the commit that would be created if the merge request was merged at the time the pipeline is created) rather than the tip of the source branch. Every time the target branch changes, the merge request pipeline results become stale. If the merge request pipeline must be green before merge, the tests must be re-run competing with others to merge. ### Vision It should be possible to merge a merge request before the pipeline is complete, assuming there are no conflicts and CI passes. GitLab should make it possible to merge commits easily while guaranteeing only green merges without people needing to fight for a merge slot. ### Proposal The **Merge When Pipeline Succeeds** button should automatically retry and queue merge requests for greater efficiency. **One-click "Rebase, and then Merge When Pipeline Succeeds"** This brings all merge strategies into parity, so that all merge strategies are blocked by the equivalent retry problem. **Merge queue MVC** When clicking MWPS succeeds, GitLab will add the merge request to merge queue (first in first out). A new merge ref will be created based on the merge request's position in the merge queue and the assumption that all preceding merge requests will succeed If a merge request in the merge queue fails, that merge request will be removed from the queue (equivalent to MWPS failing), and the merge queue will be cleared. The **Merge Immediately** option, which already exists for MWPS, will allow urgent merge requests to jump the queue. The merge queue will be cleared. High priority improvements: - gracefully handle merge request failing rather than emptying the queue - gracefully handle urgent merge requests jumping the queue rather than emptying the queue - view and reorder the merge queue Other improvements: - limit max queue size to prevent too many CI resources being wasted – this is a low priority optimization because the queue will use less CI resources than re-running every single job every time a merge happens. ### Related problems - https://gitlab.com/gitlab-org/gitlab-ee/issues/7380