GitLab CI Setting a variable within another variable

Viewed 519

I've got a CI script setup something like this with 3 files :

# file Vars
.def-vars:
    STAGING_SSH_DEST: mysite.com
    PROJECT_ROOT: myRoot
# file gitlab-ci
variables:
    extends: .def-vars
    STAGING_SSH_DEST: myrealsite.com
    PROJECT_ROOT: /myRealRoot

deploy-stage:
    extends: .deploy
    variables:
        SSH_DESTINATION: $STAGING_SSH_DEST
# file deploy
.deploy:
    variables:
        SSH_DESTINATION: mysite.com
        RSYNC_DESTINATION: $SSH_DESTINATION:$PROJECT_ROOT

I have my files and variables split up like this to increase the re-usability of the scripts.

The idea was that since I have multi site destinations, staging prod, I want to be able to pass the ssh destination to each and have the job figure out the rsync on its own. Problem is, the variable expansion is not working the way I'd think it would.

In the deploy script I added a print and got the following :

$ echo $SSH_DESTINATION            # This is the variable name local to job
   myrealsite.com                  # Yep! printed the passed in value
$ echo $RSYNC_DESTINATION          # $SSH_DESTINATION:$PROJECT_ROOT
   $STAGING_SSH_DEST:/myRealRoot   # That is the name of the variable passed in

The root and SSH_DESTINATION print just fine. When appending the two, the former seems to be expanded one too few times.

I've had the idea to just create the rsync variable within the script section but I'd like to avoid this as I want to be able to override the rsync variable without editing the .deploy job.

How can this be accomplished?

1 Answers

There is an issue with Gitlab CI variables, preventing you to expand variables correctly with your extends setup. Your options to solve this are:

  • Use this solution with the help of before_script, posted inside aforementioned issue. Some limitations are there, but for simple stuff it is working pretty good.
 before_script:
   - export VAR1="${CI_PIPELINE_ID}"
   - export VAR2="test-${VAR1}"
  • Do some kind of preparation via .env artifacts and downstream pipelines. This one is tougher to setup, but it will allow to create dynamic tasks (and pipelines), for example spawning multi-stage deploy after successful build.
Related