Allow predefined variables to be used in YAML-defined variables

Summary

A user should be able to use the predefined variables inside a YAML-defined variable.

variables:
  VENV_ROOT: C:\temp\%CI_PROJECT_ID%      # Project #85

When the above is run, VENV_ROOT is the raw string C:\temp\%CI_PROJECT_ID% rather than C:\temp\85

Usage Case

I need to create a long variable that's essentially C:\temp\%CI_PROJECT_ID%\%CI_BUILD_REF_NAME%\%CI_BUILD_NAME%\ and use this in multiple locations in the ci YAML file. If I want to change this path at a later date, I have to change all instances of it.

Having it as a YAML-defined variable will reduce chance of mistakes and make things easier to maintain.

Versions, etc.

• GitLab-Multi-Runner 1.0.4 (014aa8c) on Windows.
• GitLab CE v8.5.2

Is this still an issue with recent GitLab Runner versions?

Added waiting for feedback label

@tmaczukin I checked the changelog and didn't see anything that stood out as a fix or alternate method.

Could you tell me what change you are thinking of that might solve this issue?

Thanks

---

I'm now running runner v1.5.2 and nothing has changed. Here's the relevant portion of my .gitlab-ci.yml:

variables:
  VENV_ROOT: C:\temp\builds
  VENV_PY34: C:\temp\builds\python34_x64
  TEMP: C:\temp\%CI_PROJECT_ID%

before_script:
  - echo %TEMP%
  - echo %VENV_PY34%\%CI_PROJECT_ID%__%CI_BUILD_REF_NAME%

And this is the output, with annotations:

Running with gitlab-ci-multi-runner 1.5.2 (76fdacd)
Using Shell executor...
Running on GITLAB-CI...

Fetching changes...

HEAD is now at 296a9b4 Checking commits from TPJ.
From http://gitlab.tph.local/dthor/dummy-proj
   296a9b4..ca7f24b  master     -> origin/master
Checking out ca7f24be as master...

$ echo %TEMP%
C:\temp\%CI_PROJECT_ID%                                           // Should be "C:\temp\164"
$ echo %VENV_PY34%\%CI_PROJECT_ID%__%CI_BUILD_REF_NAME%
C:\temp\builds\python34_x64\164__master

Added improvement and removed waiting for feedback labels

@dougthor42 I'm not referencing any particular change. I only remember that variables support was changed in some way and version 1.0.4 - which you've referenced in the description - is quite old.

Thanks for the response. We'll look on this.

Awesome, thanks.

An extension of this idea would be to allow any variables (not just the predefined ones) to be used in subsequent variables. Doing so would allow for some pretty sophisticated actions.

Meaning:

variables:
  VAR1: "~/builds"
  VAR2: "$VAR1/core"             # "~/builds/core"
  VAR3: "$VAR1/test"             # "~/builds/test"
  VAR4: "$VAR5/invalid           # $VAR5 is not yet defined, so this is errors out.
  VAR5: "~/temp"

Yes, I agree that this is something that would be very usable :)

Milestone changed to %Backlog

currently (gitlab version 9.2.1-ee) i stumbled upon this problem using the public (linux) runners. it would be more than helpful to implement this feature.

at least it should be documented that this is currently not possible https://docs.gitlab.com/ee/ci/variables/README.html. would help to save some time.

I get that certain vars can not be set but they should be documented. Here is my workaround:

In my script (a template) I check are the var first with if [ -v TF_VAR_docker_image ]; then TF_VAR_docker_image=$(eval "echo $TF_VAR_docker_image"); fi ( can't start the line with [[ ...). Which expands the job var when the job is ran:

variables: 
  TF_VAR_docker_image: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG-$CI_PIPELINE_ID