Variable inside variable gitlab ci

Check out GitLab 14.3 (September 2021)

Use variables in other variables

CI/CD pipeline execution scenarios can depend on expanding variables declared in a pipeline or using GitLab predefined variables within another variable declaration.

In 14.3, we are enabling the “variables inside other variables” feature on GitLab SaaS.

Now you can define a variable and use it in another variable definition within the same pipeline.

You can also use GitLab predefined variables inside of another variable declaration.

This feature simplifies your pipeline definition and eliminates pipeline management issues caused by the duplicating of variable data.

Note - for GitLab self-managed users the feature is disabled by default.
To use this feature, your GitLab administrator will need to enable the feature flag.

(demo -- video)

See [Documentation]https://gitlab.com/gitlab-org/gitlab/-/blob/ee8cb300efb6f917eab6d865c9d430eb62077b44/doc/ci/variables/index.md#use-variables-in-other-variables) and Issue.

Q4 2023: the documentation now refers to Use CI/CD variables in other variables

Use CI/CD variables in other variables

You can use variables inside other variables:

job:
 variables:
   FLAGS: '-al'
   LS_CMD: 'ls "$FLAGS"'
 script:
   - 'eval "$LS_CMD"'  # Executes 'ls -al'

Use the $ character in CI/CD variables.
If you do not want the $ character interpreted as the start of another variable, use $$ instead:

job:
 variables:
   FLAGS: '-al'
   LS_CMD: 'ls "$FLAGS" $$TMP_DIR'
 script:
   - 'eval "$LS_CMD"'  # Executes 'ls -al $TMP_DIR'

Prevent CI/CD variable expansion

Introduced in GitLab 15.7.

Expanded variables treat values with the $ character as a reference to another variable.
CI/CD variables are expanded by default. To treat variables with a $ character as raw strings, disable variable expansion for the variable

dba asks in the comments:

Does this include or exclude using globally defined variables?

dba's own answer:

Global variables can be reused, but they need the local_var: ${global_var} syntax with recursive expansion (independent of the shell).

Check if this matches gitlab-org/gitlab-runner issue 1809:

Description

• In the .gitlab-ci.yml file, a user can define a variable and use it in another variable definition within the same .gitlab-ci.yml file.
• A user can also use a GitLab pre-defined variable in a variable declaration.

Example

variables:
  variable_1: "foo"           # here, variable_1 is assigned the value foo
  variable_2: "${variable_1}" # variable_2 is assigned the value variable_1. 
  #  The expectation is that the value in variable_2 = value set for variable_1

If it is, it should be completed/implemented for GitLab 14.1 (July 2021)

Lots of options.

But you could just pass the predefined var into the .env

image: busybox:latest

variables:
  MY_CUSTOM_VARIABLE: $CI_JOB_STAGE
  ANIMAL_TESTING: "cats"

before_script:
  - echo "Before script section"
  - echo $CI_JOB_STAGE
  - echo $MY_CUSTOM_VARIABLE
  - echo $MY_CUSTOM_VARIABLE >> .env
  - echo $CI_COMMIT_BRANCH >> .env
  - cat .env

example pipeline output

$ echo "Before script section"
Before script section
$ echo $CI_JOB_STAGE
build
$ echo $MY_CUSTOM_VARIABLE
build
$ echo $MY_CUSTOM_VARIABLE >> .env
$ echo $CI_COMMIT_BRANCH >> .env
$ cat .env
build
exper/ci-var-into-env
$ echo "Do your build here"
Do your build here

or pass it in earlier.

image: busybox:latest

variables:
  MY_CUSTOM_VARIABLE: "${CI_JOB_STAGE}"
  ANIMAL_TESTING: "cats"

before_script:
  - echo "Before script section"
  - echo $CI_JOB_STAGE
  - echo $MY_CUSTOM_VARIABLE
  - echo $MY_CUSTOM_VARIABLE >> .env
  - cat .env
   

example: https://gitlab.com/codeangler/make-ci-var-custom-var-in-script/-/blob/master/.gitlab-ci.yml