What happened to Merge when pipeline succeeds? GitLab auto-merge explained

If you’re looking for the Merge when pipeline succeeds button, it’s now Set to auto-merge, and it does more than the old one did. Here is what auto-merge waits for in 2026, what cancels it, and how to set it from the browser, the command line or the API.

What changed

The old button waited for one thing: the pipeline. Auto-merge waits for every merge check the project has, and merges the moment the last one passes. That behaviour, first called merge when checks pass, has been generally available since GitLab 17.7.

The old name hasn’t quite gone. The API still accepts merge_when_pipeline_succeeds, deprecated since GitLab 17.11 in favour of auto_merge, and there is a matching deprecated push option.

What auto-merge waits for

GitLab merges once all of these are true:

• every required approval has been given,
• all threads are resolved,
• there are no merge conflicts,
• the merge request isn’t a draft, is open and isn’t blocked by another merge request,
• a CI/CD pipeline has completed successfully, whatever the project’s pipeline setting,
• external status checks have passed and no security policy denies it,
• the title matches any title validation pattern, and any required Jira issue link is there,
• any Merge after date has passed.

So you can set auto-merge while checks, approvals included, are still pending, and walk away: GitLab merges when the last one passes, with no action from you. If one of these checks is what’s blocking you, why can’t I merge my GitLab merge request? goes through each.

Set it in the browser

1. Open the merge request and scroll to the merge request reports section.
2. Optionally choose merge options: Delete source branch, Squash commits or Edit commit message.
3. If the description closes an issue, check that the issue should close on merge. You can’t change which issues auto-close after auto-merge is set.
4. Select Set to auto-merge.

You need the Developer, Maintainer or Owner role. A comment with /merge works too: depending on the project, it merges when the pipeline succeeds or adds the merge request to a merge train.

GitLab’s docs add one catch: if you comment after setting auto-merge but before the pipeline finishes, the merge is blocked until all threads are resolved.

What cancels it

• A new commit to the merge request. GitLab cancels auto-merge so the new changes get a review first. Set it again after you push.
• New commits on the target branch, on projects that use the merge commit with semi-linear history or fast-forward merge method without automatic rebase before merge. With automatic rebase on, auto-merge can stay active and GitLab rebases at merge time. That change arrived in GitLab 19.3 behind a feature flag that is off by default.
• You. Select Cancel auto-merge in the reports section while the pipeline is still running. The author can, and so can anyone with the Developer role or higher.

A failed pipeline doesn’t cancel it. Retry the failed jobs, and if they pass, the merge request merges.

From the command line and the API

• GitLab CLI: glab mr merge turns on auto-merge by default while a pipeline is running. --auto-merge=false merges at once, and --squash, --rebase and --remove-source-branch set the merge options.
• Git push options: git push -o merge_request.create -o merge_request.auto_merge opens the merge request and sets it to auto-merge in one push. (merge_request.merge_when_pipeline_succeeds is the deprecated name.)
• API: PUT /projects/:id/merge_requests/:merge_request_iid/merge with auto_merge=true. To cancel, POST /projects/:id/merge_requests/:merge_request_iid/cancel_auto_merge (GitLab 19.5 and later); earlier versions use cancel_merge_when_pipeline_succeeds, which 19.5 deprecated.

Settings that change the picture

• Pipelines must succeed. In Settings › Merge requests, under Merge checks, a Maintainer or Owner can require a successful pipeline for every merge, auto or not. A merge request with no pipeline at all then can’t merge, and Skipped pipelines are considered successful decides how skipped ones count.
• Merge can start. On a merge request’s edit page, Merge can start › After scheduled date holds the merge until a date and time you choose (GitLab 17.6 and later).
• Merge trains. On projects that use them, auto-merge works with the merge train as well, generally available since GitLab 17.7.

Auto-merge from your phone

Setting auto-merge is the step that most often waits until you’re back at a desk. MergeBell’s merge sheet can set a merge request to auto-merge, with squash and delete branch, on the free tier, and it lists every check still failing, so you can see what the merge is waiting for. On Pro, a pipeline watch sends a push if the pipeline fails, with Retry on the notification.