feat(ci): expose CI_CONFIG_REF_URI as a predefined CI/CD variable

Mark Mishaevrequested to merge
markmishaev/ci-config-ref-uri-predefined-variable into master

What does this MR do and why?

Exposes the existing ci_config_ref_uri OIDC ID token claim as a predefined CI/CD environment variable CI_CONFIG_REF_URI.

GitHub Actions exposes an equivalent value as GITHUB_WORKFLOW_REF, available directly as an env var. GitLab only has this data inside the JWT payload of an ID token, which forces tools to decode the token at runtime. This creates friction for any tool that needs to identify or verify which CI config produced a pipeline run (e.g., sigstore-based keyless signing, npm/PyPI trusted publishing, nono agent attestation).

The new variable contains the fully qualified ref path to the top-level pipeline definition:

gitlab.example.com/my-group/my-project//.gitlab-ci.yml@refs/heads/main

The value is computed using the same formula as the OIDC ci_config_ref_uri claim (via Settings.build_server_fqdn, project.full_path, ci_config_path_or_default, and pipeline.source_ref_path). It is empty when source_ref_path is nil.

References

Screenshots or screen recordings

Not applicable (no UI changes).

How to set up and validate locally

  1. Create a pipeline on any branch: 
    pipeline = Ci::Pipeline.last
builder = Gitlab::Ci::Variables::Builder::Pipeline.new(pipeline)
vars = builder.predefined_variables.to_hash
puts vars['CI_CONFIG_REF_URI']
# => "localhost/root/my-project//.gitlab-ci.yml@refs/heads/main"
  2. Verify the value matches the expected format.
  3. For a project with a custom CI config path, confirm the custom path appears in the URI.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports