External "renovate/*" jobs for status checks are not (always) correctly attached to pipelines

[spodskubka]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitLab (.com or self-hosted)

Which version of Renovate are you using?

44.52.0

Please tell us more about your question or problem

Hello everyone!

I'm having trouble with the external "renovate/*" jobs for status checks, they are sometimes not correctly attached to the actual pipeline where I would expect them and where they would have an impact on the merge request status.

Our GitLab CI configuration only creates branch pipelines for special branches (e.g. main, develop), but not for Renovate branches. However, pipelines are created for each merge request.

When we started to use Renovate 9 months ago, we used the default "merge request pipelines" in GitLab MRs, which run for the head commit in the MR's source branch, in combination with merge method "Merge commit with semi-linear history", which causes Renovate to interpret rebaseWhen=auto as rebaseWhen=behind-base-branch.

Back then, when Renovate created a new branch and corresponding merge request, the first pipeline was always split like this:

The external job for the status check is shown as a separate "branch" pipeline while the regular MR pipeline is above with our own four stages. This is not what I am expecting because a red status would not block the merge.

When Renovate would rebase the branch a few days later, the status check would be correctly added as a fifth stage to the new merge request pipeline:

The way I see it, this is correct.

---

Some months ago we switched to "merged results pipelines", which are running on an internal merge commit into the target branch, created by GitLab itself.

The initial pipeline for created branches/MRs is like before, as you can see here:

In this case we have a failing post-upgrade script that should actually block the merge, but it doesn't. This is how the pipeline status looks in the MR overview:

But with "merged results pipelines", even after rebases/retries, the status check is never attached to the correct pipeline, as can be seen in this MR's pipelines:

---

I took a good look at the Renovate logs and also its source code and I think the cause for these problems may be found in the Renovate workflow and the GitLab platform integration code. What I can't judge is whether something can be done to fix this.

1. It seems Renovate pushes the first status check jobs to GitLab after creating the branch and before creating the MR. With our configuration there doesn't exist a pipeline yet, that's why a new one with only the status check job is created. This explains the problem with the initial MR pipeline with both "merge request" and "merged results" pipelines.
2. The problem that the status checks are not correctly attached to any "merged results" pipeline probably stems from the fact that Renovate's GitLab setBranchStatus(...) function looks for a pipeline for the head commit of the branch, which never exists with this kind of pipeline. It only exists for a "fictional" merge commit.

Is this kind of GitLab configuration really not supported by Renovate or is there something I could try changing in my Renovate configuration? Anything else I could do to help in this regard?

Many thanks!

Logs (if relevant)

No response

[jamietanna]

This looks related to #45682

@RahulGautamSingh have you seen these "merged results" pipelines before? Might be worth checking if this is functionality we need to support

[RahulGautamSingh]

Thanks for the writeup @spodskubka, both of your diagnoses are correct. They're two separate problems though.

1. The status job spawning its own branch pipeline

This is the pre-MR setBranchStatus call, exactly as you read it. Already fixed, but behind a flag:

RENOVATE_X_GITLAB_SKIP_STATUS_WITHOUT_PIPELINE=true

Renovate then skips posting the status when commits/:sha has no last_pipeline, and retries setBranchStatusChecks after the MR exists, so the status lands on the MR pipeline instead of creating one.

Shipped in 43.100.0 via #41130, so 44.52.0 already has it, it's just opt-in.

That also answers #45682.

2. Merged results pipelines

Correct, not supported today.

setBranchStatus resolves pipeline_id from GET /projects/:id/repository/commits/:branchSha → last_pipeline.id.

A merged-results pipeline runs on GitLab's internal merge ref, not on the branch head, so that lookup returns nothing regardless of rebases or retries. The status has nothing to attach to.

One warning: with the flag from (1) set, this becomes "no status posted at all" instead of "status on a stray pipeline". Neither blocks your merge, so the flag doesn't solve your real complaint, it just removes the noise.

Fix direction: we already parse head_pipeline on the MR, which is the merged-results pipeline. Falling back to that id when the commit lookup comes up empty should cover it. The open question is whether GitLab accepts POST /projects/:id/statuses/:branchSha with a pipeline_id belonging to a pipeline whose own sha is the merge-ref commit.

You asked what you could do, that's it: run that POST by hand against one of your merged-results MRs and report whether the status attaches to the pipeline. It's the one unknown blocking the fix.

---

AI assisted

[spodskubka]

1. The status job spawning its own branch pipeline

Thanks for your analysis. I will try the flag you mentioned to remove those stray pipelines.

2. Merged results pipelines

I did as you asked and executed the POST request manually.

I used one of the pipelines from my screenshot above for my test, that's how it looks before:

Note that the visible commit SHA 23f23017 is that of the merge commit that was created for the merged-results pipeline. The actual head commit of the source branch was 616c298a at that time.

I also confirmed that the GitLab "Retrieve a merge request" API via GET /projects/:id/merge_requests/:merge_request_iid returns the head commit of the source branch in sha and the merge commit in head_pipeline.sha.

This is my POST request:

curl --request POST --header "PRIVATE-TOKEN: …" 'https://…/projects/8945/statuses/23f23017c20602db774e956b94c1bbd7785e7df3?state=failed&context=renovate/artifacts&description=Artifact%20file%20update%20failure%20(test)&pipeline_id=5084835'

And its response:

{
  "id": 58451003,
  "sha": "23f23017c20602db774e956b94c1bbd7785e7df3",
  "ref": "refs/merge-requests/285/merge",
  "status": "failed",
  "name": "renovate/artifacts",
  "target_url": null,
  "description": "Artifact file update failure (test)",
  "created_at": "2026-09-22T08:31:57.545Z",
  "started_at": null,
  "finished_at": "2026-09-22T08:31:57.542Z",
  "allow_failure": false,
  "coverage": null,
  "pipeline_id": 5084835,
  "author": {
    "omitted": "for brevity"
  }
}

And this is what the pipeline looks like afterwards:

So the status attached correctly to the merged-results pipeline. 👍

[spodskubka]

@RahulGautamSingh The response you selected as answer only answers problem 1 (status on its own branch pipeline).

Regarding problem 2 (merged results pipelines), where I supplied you with proof that your suggested fix would work, I would like to know where the actual fix is tracked (you said "It's the one unknown blocking the fix."). Does an issue exist yet? Thanks!

[RahulGautamSingh]

My bad, I only skimmed and missed that part. Will get back shortly.

[RahulGautamSingh]

Thanks for testing that, and sorry, I marked the answer before following up on part 2.

Your test answered a slightly different question than the one I asked, and it is more useful than one I requested.

I asked about posting to the branch head sha with the merged-results pipeline_id. You posted to the merge-ref sha (23f23017) and it attached to the merged-results pipeline. Matching the pipeline's own sha is the cleaner fix here.

What the fix needs:

1. Read head_pipeline.id from the MR (today we only read status and sha).
2. In setBranchStatus, when the branch commit has no last_pipeline and the MR's head pipeline is a merged-results pipeline for the current branch head, post to statuses/<head_pipeline.sha> with that pipeline_id.
3. Read the status back from the same sha. Otherwise Renovate will not see its own check and will post it again on every run.

The merge ref changes whenever the target branch moves, so each new merged-results pipeline needs the status posted again. Step 3 covers that.

I opened #47063 to track this.

[RahulGautamSingh]

Fix PR: #47064

@spodskubka can you try this branch on your merged results pipelines. We have no public way to reproduce it, so your test is the only real-world check.

[spodskubka]

@RahulGautamSingh It will take some more days before I will get back to you on that. First I have to find out how to build Renovate locally in our corporate network (no access to the public NPM registry, only to company mirror) and how I can execute it locally and run it against one of my test repos.
I know the Renovate docs for local development, have already begun trying Dev Containers.

[spodskubka]

Well, I almost had it ready to test locally. But now that this change is already live in 44.181.0, it will be far easier.

Our next scheduled Renovate run is Monday morning, it will use the latest 44.* version. I should be able to report back here on Tuesday if the problem is fixed now.