[go: up one dir, main page]

Skip to content

Pipeline execution policy custom stages ignoring .pre and cannot be injected at the beginning of the pipeline

Description

Bug Description

There is a bug in how custom stages defined in Pipeline Execution Policies are being inserted into the pipeline execution order.

Current Behavior

When a Pipeline Execution Policy defines custom stages in a specific order like:

[.pipeline-policy-pre, .pre, policy-build, policy-test, policy-deploy, .post]

And a project's CI configuration defines its own stages like:

[build, test, deploy]

The custom policy stages (policy-build, policy-test, policy-deploy) are being incorrectly appended after all project-defined stages, resulting in this execution order:

[.pipeline-policy-pre, .pre, build, test, deploy, policy-build, policy-test, policy-deploy, .post]

Expected Behavior

The custom policy stages should be inserted immediately after the .pre stage as defined in the policy, resulting in this execution order:

[.pipeline-policy-pre, .pre, policy-build, policy-test, policy-deploy, build, test, deploy, .post]

Impact

This bug prevents organizations from properly enforcing their pipeline execution order through policies, which can lead to:

  • Security checks running too late in the pipeline
  • Compliance requirements not being met
  • Inefficient pipeline execution where policy-mandated jobs run after project jobs when they should run before

Steps to Reproduce

  1. Create a Pipeline Execution Policy with custom stages defined as:

    [.pipeline-policy-pre, .pre, policy-build, policy-test, policy-deploy, .post]
  2. Create a project with CI configuration that defines stages as:

    [build, test, deploy]
  3. Run a pipeline for the project

  4. Observe that the policy stages are appended after the project stages instead of being inserted after .pre

Proposal

When a Pipeline Execution Policy defines custom stages in a specific order like:

[.pipeline-policy-pre, .pre, policy-build, policy-test, policy-deploy, .post]

And a project's CI configuration defines its own stages like:

[build, test, deploy]

Allow users to specify policy jobs before .pre if they want to ensure custom stages run at the beginning of the pipeline:

[policy-build, policy-test, policy-deploy, .pre]

The full resulting pipeline including all implicit stages would be:

[.pipeline-policy-pre, policy-build, policy-test, policy-deploy, .pre, build, test, deploy, .post, .pipeline-policy-post]
Edited by 🤖 GitLab Bot 🤖