### Release notes Expose `ci_config_ref_uri` (currently only available as an OIDC ID token claim) as a predefined CI/CD environment variable `CI_CONFIG_REF_URI`, giving CI jobs direct access to the fully qualified pipeline config reference without JWT decoding. ### Problem to solve GitLab's OIDC ID token includes a `ci_config_ref_uri` claim (added in #404722, shipped in 16.2) that contains the fully qualified reference to the pipeline definition — for example: ``` gitlab.example.com/my-group/my-project//.gitlab-ci.yml@refs/heads/main ``` This value is only accessible by decoding the JWT payload of a `SIGSTORE_ID_TOKEN` (or other configured ID token). There is no equivalent predefined CI/CD variable. GitHub Actions exposes the equivalent value as `GITHUB_WORKFLOW_REF`, available directly as an environment variable in any workflow step. This creates a gap for tools that need to identify or verify which CI config produced a given pipeline run. Real-world impact: the [nono](https://github.com/always-further/nono) project (runtime security for AI agents, by the creator of Sigstore) is adding GitLab as a trusted OIDC publisher ([PR #169](https://github.com/always-further/nono/pull/169)). The contributor currently has to either hard-code `.gitlab-ci.yml` in the workflow reference (wrong when projects use custom CI config paths) or decode the JWT at runtime. Neither is ideal. The same friction applies to npm trusted publishing, PyPI trusted publishing, and any other OIDC-based verification system integrating with GitLab CI. ### Proposal Add `CI_CONFIG_REF_URI` as a predefined CI/CD variable with the same value as the existing `ci_config_ref_uri` OIDC token claim. | Variable | Value | Available | |---|---|---| | `CI_CONFIG_REF_URI` | Fully qualified reference to the pipeline definition, e.g. `gitlab.example.com/my-group/my-project//.gitlab-ci.yml@refs/heads/main` | Always (null when CI config is external to the project, matching the OIDC claim behavior) | **Implementation:** The value is already computed for the ID token claim. Exposing it as a predefined variable should be a small change — add it alongside existing variables like `CI_CONFIG_PATH` in the predefined variables list. **Precedent:** - `CI_CONFIG_PATH` already exposes the config file path (but not the fully qualified URI with host, project, and ref) - GitHub's `GITHUB_WORKFLOW_REF` provides this exact capability as a first-class env var ### Intended users * [Sasha (Software Developer)](https://handbook.gitlab.com/handbook/product/personas/#sasha-software-developer) * [Priyanka (Platform Engineer)](https://handbook.gitlab.com/handbook/product/personas/#priyanka-platform-engineer) * [Amy (Application Security Engineer)](https://handbook.gitlab.com/handbook/product/personas/#amy-application-security-engineer) ### Feature Usage Metrics Usage can be tracked by counting pipelines where `CI_CONFIG_REF_URI` is referenced in job scripts or passed to external services. ### Does this feature require an audit event? No.