<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=385841) </details> <!--IssueSummary end--> <!--This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ## Status Update (Mar 24th, 2026) We've heard consistent feedback requesting an extension to the "Pipelines must succeed" setting to also evaluate branch pipelines alongside MR pipelines. After careful consideration, we've decided not to implement that change in its proposed form. The core reason is architectural: duplicate pipelines — where both a branch pipeline and an MR pipeline run for the same commit — should not exist in the context of a merge request. This is not an intended or supported workflow, and extending "Pipelines must succeed" to accommodate it would entrench a pattern we are actively working to move away from. Instead, we are taking two complementary approaches: First, we are delivering targeted solutions for specific use cases where duplicate pipelines are being created today as a result of legitimate workflows or tooling constraints. These are pragmatic, near-term fixes designed to reduce customer impact while the broader architecture evolves. The first of these — focused on teams using Pipeline Execution Policies or Scan Execution Policies — is already in progress. Second, and more fundamentally, we are investing in architectural change that eliminates the duplicate pipeline problem at its source. Our long-term goal, tracked under Epic &amp;6044, is to ensure that at most one pipeline is created per commit in the context of a merge request. This removes the ambiguity entirely and makes merge readiness checks reliable and predictable by design. If you have a use case not covered above, or if you have questions or would like further clarity on our long-term architectural direction, please share them in the comments below. We want to make sure we have a complete picture of the workflows impacted and are happy to discuss our thinking further. ## Problem As a DevOps engineer with an external integration, I want all pipelines to be successful/checked for success before merge, so that I can be confident all compliance/security checks are done. In addition, if both `branch` and `merge request` pipelines run today it's a race to see which one will be the `primary` pipeline for the merge request to allow merge. ## Use Cases ### **Security & Compliance Scanning with GitLab Tools** We're actively working on a [dedicated solution](https://gitlab.com/gitlab-org/gitlab/-/work_items/589650) for teams using Pipeline Execution Policies (PEP) or Scan Execution Policies (SEP) to inject security scans into their merge request pipelines. Today, when a PEP or SEP injects security jobs into an MR pipeline, a separate branch pipeline often runs in parallel carrying functional tests. Because GitLab's mergeability check currently only evaluates one pipeline, a failing branch pipeline can be overlooked — allowing code with broken tests to be merged despite security scans passing. This is a targeted, near-term fix for teams impacted today, designed to complement our longer-term architectural work (Epic &amp;6044) to eliminate duplicate pipelines altogether — at which point this check will naturally become redundant. ### **External & Third Party Tool Integrations** For teams using external or third-party tools — such as security scanners, quality gates, or CI platforms like Jenkins, TeamCity, or Wiz — that create their own branch pipelines via GitLab webhooks, we currently do not have a dedicated product solution in progress for this use case. However, we have a clear best practice recommendation: rather than allowing third-party tools to create independent branch pipelines through webhooks, we recommend invoking those tools directly as jobs within a GitLab CI pipeline. This means calling the external tool from your `.gitlab-ci.yml`, with GitLab CI waiting for and capturing the result as part of the pipeline. This approach has meaningful advantages: - The external tool's result becomes part of a single, unified pipeline that GitLab's merge checks can evaluate reliably - It eliminates the race condition between independently created pipelines competing to determine merge readiness - It gives teams full visibility into all checks in one place within the merge request We recognize this requires changes on your side — specifically, updating how your third-party tools are invoked rather than relying on webhook-driven pipeline creation. ## Proposal Add a setting to choose which pipeline / both latest pipelines must be successful if a project is setup to run both pipelines. - This might be the case for external service checks like a security tool running in its own branch pipeline.