Conditional variables in gitlab-ci.yml

Question

Depending on branch the build comes from I need to use slightly different command line arguments. Particularly I would like to upload snapshot nexus artifacts when building from a branch, and release artifact when building off master.

Is there a way to conditionally alter variables?

I tried to use except/only keywords like this

stages:
    - stage


variables:
    TYPE: Release


.upload_common:
    stage: stage
    tags: ["Win"]
    script: 
        - echo Uploading %TYPE%


.upload_snapshot:
    variables:
        TYPE: "Snapshot"
    except:
        - master


upload:
    extends: 
        - .upload_common
        - .upload_snapshot

Unfortunately it skips whole upload step when building off master.

The reason I am using 'extends' pattern here is that I have win and mac platforms which use slightly different variables substitution syntax ($ vs %). I also have a few different build configuration - Debug/Release, 32bit/64bit.

The code below actually works, but I had to duplicate steps for release and snapshot, one is enabled at a time.

stages:
    - stage


.upload_common:
    stage: stage
    tags: ["Win"]
    script: 
        - echo Uploading %TYPE%


.upload_snapshot:
    variables:
        TYPE: "Snapshot"
    except:
        - master

.upload_release:
    variables:
        TYPE: "Release"
    only:
        - master


upload_release:
    extends: 
        - .upload_common
        - .upload_release


upload_snapshot:
    extends: 
        - .upload_common
        - .upload_snapshot

The code gets much larger when snapshot/release configuration is multiplied by Debug/Release, Mac/Win, and 32/64bits. I would like to keep number of configurations at minimum.

Having ability to conditionally altering just a few variables would help me reducing this code a lot.

Specifically for the permutation style combinations, check [`parallel:matrix:`](https://docs.gitlab.com/ee/ci/yaml/#parallelmatrix) as well. — Robert Cutajar, Aug 16 '23 at 22:13

score 67 · Answer 1 · edited Aug 16 '23 at 21:29

Another addition in GitLab 13.7 are the rules:variables. This allows some logic in setting vars:

job:
  variables:
    DEPLOY_VARIABLE: "default-deploy"
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:                              # Override DEPLOY_VARIABLE defined
        DEPLOY_VARIABLE: "deploy-production"  # at the job level.
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      variables:
        IS_A_FEATURE: "true"                  # Define a new variable.
  script:
    - echo "Run script with $DEPLOY_VARIABLE as an argument"
    - echo "Run another script if $IS_A_FEATURE exists"

It can also be done on workflow level for the whole pipeline:

workflow:
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:
        DEPLOY_VARIABLE: "deploy-production"
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      variables:
        IS_A_FEATURE: "true"

Then consider though that workflow rules affect the whole pipeline. You'll need to cover all your use cases.

keep in mind, it can duplicate pipelines https://docs.gitlab.com/ee/ci/jobs/job_control.html#avoid-duplicate-pipelines — anydasa, Apr 11 '23 at 17:25

vak · Answer 2 · 2019-08-16T11:37:26.387

Unfortunatelly YAML-anchors or GitLab-CI's extends don't seem to allow to combine things in script array of commands as of today.

I use built-in variable CI_COMMIT_REF_NAME in combination with global or job-only before_script to solve similar tasks without repeating myself.

Here is an example of my workaround on how to set environment variable to different values dynamically for PROD and DEV during delivery or deployment:

.provide ssh private deploy key: &provide_ssh_private_deploy_key
  before_script:
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - |
      if [ "$CI_COMMIT_REF_NAME" == "master" ]; then
        echo "$SSH_PRIVATE_DEPLOY_KEY_PROD" > ~/.ssh/id_rsa
        MY_DYNAMIC_VAR="we are in master (PROD)"
      else
        echo "$SSH_PRIVATE_DEPLOY_KEY_DEV" > ~/.ssh/id_rsa
        MY_DYNAMIC_VAR="we are NOT in master (DEV)"
      fi
    - chmod 600 ~/.ssh/id_rsa


deliver-via-ssh:
  stage: deliver
  <<: *provide_ssh_private_deploy_key
  script:
    - echo Stage is deliver
    - echo $MY_DYNAMIC_VAR
    - ssh ...

Also consider this workaround for concatenation of "script" commands: https://stackoverflow.com/a/57209078/470108

hopefully it helps.

Pardon my ignorance, but someone can explain to me what does the pipe in line 6: `- |`? — Erdal G., Mar 01 '21 at 11:32
@ErdalG. it is YAML feature, a block-line style indicator for multi-line strings — vak, Mar 03 '21 at 09:04

score 2 · Answer 3 · answered Jul 08 '21 at 11:07

A nice way to prepare variables for other jobs is the dotenv report artifact. Unfortunately, these variables cannot be used in many places, but if you only need to access them from other jobs scripts, this is the way:

# prepare environment variables for other jobs
env:
  stage: .pre
  script:
    # Set application version from GIT tag or fake it
    - echo "APPVERSION=${CI_COMMIT_TAG:-0.1-dev-$CI_COMMIT_REF_SLUG}+$CI_COMMIT_SHORT_SHA" | tee -a .env
  artifacts:
    reports:
      dotenv: .env

In the script of this job you can conditionally prepare and write your environment values into a file, then make a dotenv artifact out of it. Subsequent - or better yet dependent - jobs will pick up the variables for their scripts from there.

Conditional variables in gitlab-ci.yml

3 Answers3