PEP prefilled variables fail to load on Run Pipeline page when project's .gitlab-ci.yml is invalid in isolation

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

Summary

Prefilled variables defined in a Pipeline Execution Policy (PEP) YAML do not appear on the Run new pipeline page for a project assigned to the policy when that project's own .gitlab-ci.yml is not a valid CI config when parsed in isolation, even when the PEP uses pipeline_config_strategy: override_project_ci and would make the runtime config valid.

The PEP itself syncs and runs correctly at pipeline-creation time. The issue is specific to the prefill-listing path used to render the Run Pipeline form.

Discovered while investigating customer reports following migration from Compliance Pipelines to Pipeline Execution Policies. See root-cause analysis in #599568 (Internal Discussion).

Steps to reproduce

  1. Create a PEP at the group level with pipeline_config_strategy: override_project_ci that defines prefilled variables, includes the consumer project's local CI config (guarded with rules: per our documentation), and has at least one visible job. Example PEP YAML:

    include:
  - project: '$CI_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_SHA'
    rules:
      - exists:
          paths:
            - '$CI_CONFIG_PATH'
          project: '$CI_PROJECT_PATH'
          ref: '$CI_COMMIT_SHA'

variables:
  PEP_VARIABLE:
    value: ""
    description: "Example prefilled variable defined in the PEP YAML"

policy-job:
  script:
    - echo $PEP_VARIABLE

  2. Assign the PEP to a project whose .gitlab-ci.yml only contains a variables: block (no jobs), for example:

    variables:
  SOME_VAR: "value"

  3. Navigate to Build → Pipelines → Run pipeline on that project.

A confirmed reproducer pattern:

  • main branch with a variables-only .gitlab-ci.yml: prefilled variables do not load
  • branch with a local job added to .gitlab-ci.yml: prefilled variables do load

What is the current bug behavior?

The prefill-listing service fails to parse the project's .gitlab-ci.yml in isolation and returns no prefilled variables from the PEP. The Run Pipeline form shows none of the PEP-defined prefilled variables.

Concrete example: a project whose .gitlab-ci.yml only declares variables: (no jobs) returns the parser error ["jobs config should contain at least one visible job"] during prefill listing, even though at runtime the PEP provides the jobs and the pipeline runs successfully.

What is the expected correct behavior?

Prefilled variables defined in an applicable PEP YAML should appear on the Run new pipeline page for assigned projects regardless of whether the project's standalone .gitlab-ci.yml is a complete/valid CI config on its own, mirroring the way the actual pipeline-creation path correctly composes the PEP and project configs together.

Output of checks

This bug happens on GitLab.com.

Possible fixes

Root cause

Ci::ListConfigVariablesService does not build or pass the pipeline_policy_context to the CI config parser. The parser therefore evaluates the project's .gitlab-ci.yml standalone and fails when that config is incomplete or invalid in isolation, even when the project has an override_project_ci PEP that would make the resulting runtime config valid. The failure short-circuits before PEP prefill variables are merged in, so the Run Pipeline form silently shows none of the PEP's prefilled variables.

Relevant code:

At pipeline creation time, pipeline_policy_context is built and passed through the chain; the prefill-variable listing path does not have parity with that.

Proposed direction

Build the PEP's pipeline_policy_context inside Ci::ListConfigVariablesService (and propagate it to Gitlab::Ci::ProjectConfig) so the prefill parsing path has the same context that the runtime pipeline-creation path has.

Impact

  • Customers migrating from Compliance Pipelines to Pipeline Execution Policies (required by GitLab 19.0) experience a regression in prefilled variable behaviour.
  • Workarounds require modifying every consumer project's .gitlab-ci.yml to add a no-op job, which is not feasible at scale (1000+ projects in reported cases).
  • Mandatory audit/compliance variables that rely on prefill prompting are silently dropped, leading to pipelines being run without required inputs.

Related

Edited by 🤖 GitLab Bot 🤖