Exceptions to Bypass "Pipeline Must Succeed" Setting

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

Introduce the ability to define exceptions for the “Pipeline must succeed” setting, allowing authorized users to approve and merge Merge Requests (MRs) even when a pipeline has failed.
This feature would extend the recent Merge Request Approval Policy Exceptions capability (introduced in GitLab 18.5) to pipeline enforcement, providing flexibility while maintaining strong governance and auditability.

Background / Problem Statement

When the “Pipeline must succeed” project setting is enabled, GitLab enforces that all pipelines must pass before merging.
This ensures stability and code quality but introduces challenges when failures are due to:

  • Known false positives (e.g., in security scanning)
  • Non-critical or environment-related issues (e.g., flaky tests, temporary CI/CD outages)
  • Emergency or time-sensitive fixes that require controlled exceptions

Currently, the only workaround is to temporarily disable the “Pipeline must succeed” setting at the project level.
This approach is not auditable, reduces governance, and introduces unnecessary risks in compliance-bound environments.

Organizations often have designated Security Officials or Release Managers who have the authority to review and approve such exceptions. However, there is currently no built-in mechanism in GitLab to allow specific users to override the “Pipeline must succeed” rule in a traceable, policy-driven way.

Proposed Solution

Extend the exception handling model (as introduced for MR Approval Policies in GitLab 18.5) to support the “Pipeline must succeed” requirement.

Key Capabilities

  1. Exception Role Definition

    • Allow project/group administrators to define specific users or groups (e.g., Security Officials, Release Managers) who can override the “Pipeline must succeed” requirement.

  2. Controlled Approval Workflow

    • If a pipeline fails, the MR remains blocked until one of the designated exception users provides explicit approval to proceed with the merge.

  3. Auditable Actions

    • Record all exception approvals in:
      • MR activity logs
      • Audit events
      • Compliance dashboards (if applicable)
    • Include details such as the approver, timestamp, and justification note.

  4. Optional Policy Scoping

    • Allow administrators to configure exception rules, such as:
      • Branch-based restrictions (e.g., only for hotfix/*)
      • Failure-type filters (e.g., allow override for failed SAST jobs only)
      • Time-based or environment-based exceptions

Example Workflow

  1. A Merge Request fails due to a false-positive vulnerability in SAST.
  2. The MR remains blocked by the “Pipeline must succeed” rule.
  3. A designated Security Official reviews the results and determines it’s a false positive.
  4. The Security Official provides an explicit override approval, which:
    • Logs the exception
    • Allows the MR to be merged despite the failed pipeline
  5. The approval is fully auditable and visible in the MR timeline and compliance reports.

Benefits

  • Governance: Maintains compliance while introducing flexibility for controlled exceptions.
  • Traceability: Provides full audit logging of override decisions.
  • Efficiency: Eliminates the need to disable critical project settings for edge cases.
  • Trust & Accountability: Ensures only authorized and accountable personnel can perform overrides.

Use Cases

  • Security exceptions: Approve merges when pipelines fail due to false positives in security scans.
  • Infrastructure failures: Allow Release Managers to merge urgent fixes when failures are due to CI/CD outages or flaky tests.
  • Regulated environments: Support compliance workflows that require approval from designated officials for any exceptions.

References

Additional Notes

This enhancement would align with GitLab’s direction toward policy-driven flexibility, enabling secure exception handling across both approval policies and pipeline enforcement.
By extending the existing exceptions framework, this feature can reuse much of the current approval infrastructure, ensuring consistency and minimal implementation overhead.

Edited by 🤖 GitLab Bot 🤖