Skip to content
Fran Gonzalez
← Back to blog
(updated Jul 16, 2026)·Clanker·2 min read

GitLab CI auto_cancel can silently drop pipelines after MR rebase

When auto_cancel: on_new_commit is configured, rebasing a merge request from the GitLab web UI can prevent the new pipeline from spawning entirely.

Today I Learned#gitlab#ci#pipeline
Some matmuls wrote this slop, sorry. My goal with this content is to document some work I (a real human bean) do while poking the Clanker, and try to learn something along the way.

When workflow:auto_cancel:on_new_commit is set to interruptible, rebasing a merge request from the GitLab web UI can silently prevent the new pipeline from spawning.

What I Learned

I had an open MR with a running pipeline. I clicked the “Rebase” button in the GitLab MR web UI. The rebase created a new commit, the old pipeline was cancelled, but the new pipeline never appeared. The MR showed no CI running at all. Same result with git commit --amend --no-edit && git push --force-with-lease: no pipeline was auto-created. This is a known platform issue, not a misconfiguration.

GitLab’s auto_cancel system distinguishes between two pipeline source categories: ci_sources (trigger auto-cancel: push, merge_request_event, schedule, and most others) and dangling_sources (do not trigger auto-cancel: webide, parent_pipeline, ondemand_dast_scan, ondemand_dast_validation, security_orchestration_policy). The webide source corresponds to the “Run Pipeline” button in the GitLab UI, and pipelines started from the web interface are explicitly excluded from the auto-cancel trigger. This is documented in GitLab issue #437930 and visible in the source code.

When you rebase an MR via the web UI, GitLab pushes a new commit. This should create a merge_request_event pipeline (in ci_sources), but a race condition between cancelling the old pipeline and creating the new one can cause the new pipeline to never spawn. The original feature issue #412473 and related forum reports confirm this has been a recurring edge case.

The workaround is to manually trigger the pipeline:

glab api -X POST "projects/OWNER%2FREPO/merge_requests/43/pipelines"

Or use “Run Pipeline” from the MR page in GitLab. Commits pushed via git push from a terminal work fine; only web-initiated actions seem affected.

References

This post was written with AI assistance.