Global variable doesn't expand in job variable of same name

Summary

When the value of a job-level variable is set as a reference to a global-level variable of the same name, the global-level variable is not expanded and the value of the job-level variable is set to the literal string of the global-level variable reference.

The impact is that jobs that set default values for variables can't be configured using global variables of the same name.

A workaround is to create an intermediate global-level variable referencing the original but with a different name, and set the job-level variable using that. This adds noise to the pipeline, degrading maintainability.

Steps to reproduce

Create a pipeline with:

  1. A global variable named FOO, with value "BAR"
  2. A job declaring a variable named FOO, with value $FOO
  3. See that $FOO evaluates to "$FOO" and not "BAR" in the job

Example Project

https://gitlab.com/drew.gingerich/demo-of-gitlab-issue-433964

What is the current bug behavior?

The value of the job-level variable is set to the literal string of the global-level variable reference.

What is the expected correct behavior?

The value of the job-level variable is set to the value of the global-level variable.

Relevant logs and/or screenshots

Short example gitlab-ci.yml:

variables:
  FOO: "BAR"

stages:
  - test

overwrite-same-name:
  stage: test
  variables:
    FOO: $FOO
  script: echo $FOO

The job logs show the value of $FOO getting set as the string "$FOO", rather than the expected value "BAR".

Running with gitlab-runner 16.6.0~beta.105.gd2263193 (d2263193)
  on blue-2.saas-linux-small-amd64.runners-manager.gitlab.com/default XxUrkriX, system ID: s_f46a988edce4
  feature flags: FF_USE_IMPROVED_URL_MASKING:true
Preparing the "docker+machine" executor 00:21
Using Docker executor with image ruby:3.1 ...
Pulling docker image ruby:3.1 ...
Using docker image sha256:fca05101737f6558b05457d802cba2a21bf758fcefd856a0f4a7bbb03236a30d for ruby:3.1 with digest ruby@sha256:d3a3717a11657ab20edfc6dda9bcdc9d352bcb7cd926bf2d6bdc46cc52816b6a ...
Preparing environment 00:05
Running on runner-xxurkrix-project-52764035-concurrent-0 via runner-xxurkrix-s-l-s-amd64-1701738168-b1893ca7...
Getting source from Git repository 00:01
Fetching changes with git depth set to 20...
Initialized empty Git repository in /builds/drew.gingerich/demo-of-gitlab-issue-433964/.git/
Created fresh repository.
Checking out 4ec0a985 as detached HEAD (ref is main)...
Skipping Git submodules setup
$ git remote set-url origin "${CI_REPOSITORY_URL}"
Executing "step_script" stage of the job script 00:00
Using docker image sha256:fca05101737f6558b05457d802cba2a21bf758fcefd856a0f4a7bbb03236a30d for ruby:3.1 with digest ruby@sha256:d3a3717a11657ab20edfc6dda9bcdc9d352bcb7cd926bf2d6bdc46cc52816b6a ...
$ echo $FOO
$FOO
Cleaning up project directory and file based variables 00:00
Job succeeded

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

None

Results of GitLab application Check

None

Possible fixes

Unknown. Could be related to #432469 (closed).

Edited by Drew Gingerich