Renovate auto merging MRs with failed pipeline

[RahulGautamSingh]

Discussed in #46225

When Renovate turns on GitLab auto-merge, it waits until the MR is mergeable and has a pipeline. It accepts a failed pipeline and doesn't check that the pipeline belongs to the MR's latest commit.

If Renovate has just pushed and GitLab hasn't created a pipeline for that commit yet, PUT /merge with merge_when_pipeline_succeeds=true has no pipeline to wait for. Without "Pipelines must succeed", GitLab then merges straight away. The failed pipeline on the MR belongs to the previous commit. You should see a Renovate push in the MR activity shortly before the merge.

Workaround: enable Merge checks > Pipelines must succeed, or set "platformAutomerge": false.

The fix on our side is for tryPrAutomerge to require pipeline.sha === sha before enabling auto-merge.

[pdecat]

Hi, data point on the scale of this, and one correction on the workaround.

I swept a self-hosted Gitlab 19.3.2 instance: of 5313 bot-authored merge requests merged over six weeks, 201 across 56 projects were merged with no pipeline having validated the merged commit.
The split is bimodal with nothing in between, which is what makes it clearly this race and not something else: 67 were merged less than 30 seconds after the pipeline for the merged commit was created, and 102 before any pipeline for that commit existed at all. In 159 of the 169 that had a branch pipeline attached, the pipeline Renovate looked at was red. The signature to search for is a merged MR whose head_pipeline.sha is not its sha, filtering out merge_request_event head pipelines, which legitimately carry a different sha.

The correction: enabling Merge checks > Pipelines must succeed does not fully protect. 24 of those 201 merges are on projects that have it enabled, spread over a month and several teams, so it is not a late settings change. GitLab's own check reads diff_head_pipeline, which is nil in exactly the same window, so it has nothing to fail on.

platformAutomerge: false is the only workaround as of now IMO.

Two bits of GitLab context that suggest this will not go away on its own. The immediate-merge fallback became unconditional in 19.0: it shipped in 18.11 behind merge_immediately_when_no_pipeline (off by default) and the flag was deleted in 355d777b, first released in v19.0.0. And the GitLab-side fix, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/232296, was merged on 3 June, reverted the next day over a Sidekiq argument compatibility issue, and its re-roll was closed as stale on 3 September, with https://gitlab.com/gitlab-org/gitlab/-/issues/595420 still open.

So the pipeline.sha === sha guard is probably the only thing that will help for a while.

Edit: I ran the inverse as a control, 5068 merge requests merged on the same instance over the same two months that the bot did not author, humans and other service accounts included, classified exactly the same way. Zero hits, against 201 for Renovate.
So the entire measured population comes through tryPrAutomerge, and the pipeline.sha === sha guard would have removed all of it.