Cyclic reference in variables

Summary

When defining a variable from an input that has the same name as the one passed to the input, the variable does not get expanded.

Steps to reproduce

  1. Create a new project
  2. Create a CI/CD variable named PRIVATE_TOKEN, with the value "private"
  3. Add a .gitlab-ci.yml file to the repo with the follow content:
include:
  - local: template.yml
    inputs:
      private_token: $PRIVATE_TOKEN
  1. Add a template.yml file to the repo:
spec:
  inputs:
    private_token:
      default: ""
      description: "Access token"
---

token-size:
  script: |
    if [ -z "$PRIVATE_TOKEN" ]; then
      echo "Error: Environment variable $PRIVATE_TOKEN is not set or empty."
      exit 1
    fi
  
    echo "Size of the token"
    echo -n "$PRIVATE_TOKEN" | wc -c
  variables:
    PRIVATE_TOKEN: $[[ inputs.private_token ]]
  1. Make sure to use PRIVATE_TOKEN as the variable name, same as the CI/CD variable.
  2. Run a pipeline
  3. Notice that the output is:
Size of the token
14

which is the length of PRIVATE_TOKEN, instead of 8, the length of private

  1. Enable Expand variable reference in the settings of the CI/CD variable
  2. Run another pipeline on the same ref (main branch)
  3. The output is now 8.

Example Project

Here is a test project: https://gitlab.com/plafoucriere/component-test/

The output is 14 instead of 26: https://gitlab.com/plafoucriere/component-test/-/jobs/7709682311 With Expand variable reference enabled: https://gitlab.com/plafoucriere/component-test/-/jobs/7713365655

(note that these two jobs are for the same commit sha 4a8ffeb1fa0730b8ef97690c681ad4fb3c82f96b)

When the CI/CD variable has a different name, the component works as expected (output is 26): https://gitlab.com/plafoucriere/component-test/-/jobs/7721399783

What is the current bug behavior?

If a variable is defined from a CI/CD variable, and the have the same name, the CI/CD variable MUST have Expand variable reference otherwise the name of the variable is used, not its value.
Using different names solves the problem, but it creates a pitfall for anyone creating components.

What is the expected correct behavior?

Name of the variable should not matter, and I should not have to use Expand variable reference in this context.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of: sudo gitlab-rake gitlab:check SANITIZE=true)

(For installations from source run and paste the output of: sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)

(we will only investigate if the tests are passing)

Possible fixes