Pipeline Execution Policy jobs omit CI_PIPELINE_IID runner tag after upgrade to 19.4.2

Summary

A customer reports that Pipeline Execution Policy jobs omit a runner tag defined as ${CI_PIPELINE_IID} after upgrading GitLab Self-Managed from 19.2.7 to 19.4.2. The same policy YAML reportedly worked before the upgrade and was not changed.

This is a customer-reported suspected regression. Support has not independently reproduced the policy-specific behavior or confirmed a root cause or introducing change.

Reported environment

• GitLab Self-Managed Ultimate, Helm installation.
• Previous version: 19.2.7. Affected version: 19.4.2-ee.
• GitLab Runner: 18.6.6.
• Upgrade performed October 12, 2026; issue first observed October 13, 2026.
• A dedicated runner is provisioned for each pipeline with tags docker-apps and the pipeline IID.

Reported configuration and reproduction scenario

The relevant policy job excerpt, normalized for readability, is:

02_Code-review:
  stage: .pipeline-policy-pre
  tags:
    - $RUNNER_TAG
    - ${CI_PIPELINE_IID}

Other policy-injected preparation jobs use the same tags. This excerpt is not a complete standalone reproduction; the full policy and runner-provisioning configuration are not yet available.

1. Provision a runner for a pipeline with tags docker-apps and the pipeline IID, for example 510.
2. Run a pipeline containing policy-injected preparation jobs with the tags above.
3. Inspect the job and runner tags. With multiple matching runners active, inspect which runner receives each job.

These steps describe the customer's scenario, not an independently verified minimal reproduction.

Observed behavior

The customer captured these values in an affected policy job:

CI_PIPELINE_IID=510
CI_RUNNER_TAGS=["docker-apps", "510"]
CI_JOB_TAGS=["docker-apps"]
CI_SERVER_VERSION=19.4.2-ee

The job log identifies the job as triggered by the Pipeline Execution Policy. The pipeline-specific tag is absent from CI_JOB_TAGS, although the selected runner has both tags and the variable is available at job runtime. Runtime availability alone does not establish availability when job tags are expanded.

The customer reports jobs in the same pipeline executing on different runner hosts when multiple runners with the common tag are active. Dependent jobs then fail because pipeline assets stored on another runner's local filesystem are unavailable. Reported errors:

cd: /srv/gitlab-ci/shared/.workdir/.pipeline-assets: No such file or directory
Missing file error: /srv/gitlab-ci/shared/.workdir/.pipeline-assets/functions.sh: No such file or directory

Expected behavior

Policy jobs should retain both configured tags after expansion, for example ["docker-apps", "510"], making them eligible only for a runner matching both tags.

Impact and mitigation

Intermittent pipeline failures reportedly affect multiple projects. The customer avoids concurrent pipelines within a project and manually cleans up runners left active after failed or canceled pipelines. Pipelines reportedly generally complete when only one matching runner is active.

No product fix or fixed release has been verified.

Investigation gaps

• Compare a regular project CI job and a policy-injected job using the same direct ${CI_PIPELINE_IID} tag on the affected version.
• Obtain the complete sanitized policy and included job configuration, including the source and definition of RUNNER_TAG.
• Confirm runner scope and runner-provisioning/tag-registration sequence.
• Determine whether omission depends on pipeline source or other configuration.
• Compare identical minimal configurations on 19.2.7 and 19.4.2 to establish the regression boundary.

Related reports, not established duplicates

• Nested variable expansion in job tags: the missing tag here directly references the predefined CI_PIPELINE_IID variable.
• CI variables unavailable in Pipeline Execution Policy jobs: that report concerns project- or instance-level variables rather than this predefined variable.

Customer identities, instance URLs, and runner hostnames are omitted from this public report.