Extra branch pipeline created when setting status checks with MR pipelines (GitLab)

[secustor]

Discussed in #41129

^{Originally posted by fgreinacher February 12, 2026}

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitLab.com and GitLab Self-hosted

Which version of Renovate are you using?

v43

Please tell us more about your question or problem

When a GitLab project is configured to use MR (merge request) pipelines, Renovate creates an unwanted additional branch pipeline when setting stability/confidence status checks:

This causes multiple problems:

• Wasted CI resources / minutes: The extra pipeline runs CI jobs unnecessarily, consuming runners and GitLab CI minutes quota
• Branch pipeline may fail: Projects configured for MR-only pipelines often use $CI_MERGE_REQUEST_* variables in their CI config that aren't available in branch pipelines, causing failures
• Confusing status: Two pipelines on the same commit make it unclear which result matters
• May block automerge: A failing branch pipeline can prevent Renovate from automerging, even though the MR pipeline succeeded

Root cause

Status checks are set before the MR exists. In processBranch(), setStability() and setConfidence() are called before ensurePr(). For new branches, the MR hasn't been created yet, so GitLab has no MR pipeline. setBranchStatus() posts the commit status via POST /projects/:id/statuses/:sha without a pipeline_id, which causes GitLab to create a branch pipeline.

Expected behavior

Renovate should associate the commit status with the existing MR pipeline and not trigger a separate branch pipeline.

Current behavior

An additional branch pipeline is created every time Renovate sets a stability or confidence status check on a branch that uses MR pipelines.

Reproduction

See https://gitlab.com/fgreinacher/renovate-status-check-extra-branch-pipeline/-/merge_requests/7/pipelines

Logs (if relevant)

n/a

[viceice]

Marking as feature because it's a gitlab limitation. we don't know if a pr exists when we set the status checks.
I'm not really sure how this can be resolved 🤔

[fgreinacher]

Marking as feature because it's a gitlab limitation. we don't know if a pr exists when we set the status checks. I'm not really sure how this can be resolved 🤔

Fully agree, it's a GitLab limitation. I have a suggestion in #41130, would be great to get your feedback there 🙇

[Sillocan]

https://docs.gitlab.com/ci/ci_cd_for_external_repos/external_commit_statuses/#pipeline-selection

In your example, renovate ran before GitLab created the pipeline so #3 got hit:

If no suitable pipeline exists, GitLab creates a new pipeline to contain the job. For new pipelines, CI_PIPELINE_SOURCE is external.

Ensuring a pipeline_id is passed will def help here