Variables not dereferencing as expected in CI jobs in 16.4
Summary
US Government customer reports that after upgrading from 16.3.5 to 16.4.2 that CI jobs fail when they rely on multiple de-references of a variable--they have particularly noticed CI_ENVIRONMENT_URL is problematic.
On a call, they showed a failed deployment job (sanitized logs to come) where the deployment failed because variable for the environment name was not dereferenced as expected.
They have a workaround for some of this behavior at the moment, but may be encountering new variants of the behavior.
CSM: @rcain
Steps to reproduce
Here is an example ci file: 7043_gitlab-ci.yml and an excerpt from same:
variables:
PREDEF_FIRST: $CI_PROJECT_NAME
PREDEF_SECOND: $PREDEF_FIRST
PREDEF_THIRD: $PREDEF_SECOND
STATIC_FIRST: first_level
STATIC_SECOND: $STATIC_FIRST
STATIC_THIRD: $STATIC_SECOND
CI_ENVIRONMENT_URL: http://example.com
SOME_OTHER_VAR: http://example.com
CI_ENVIRONMENT_URL, top vars:
environment:
name: test_env
url: $CI_ENVIRONMENT_URL
script:
- set -e
- echo $PREDEF_FIRST
- echo $PREDEF_SECOND
- echo $PREDEF_THIRD
- echo $STATIC_FIRST
- echo $STATIC_SECOND
- echo $STATIC_THIRD
- "[ $PREDEF_FIRST == $CI_PROJECT_NAME ]"
- "[ $PREDEF_SECOND == $CI_PROJECT_NAME ]"
- "[ $PREDEF_THIRD == $CI_PROJECT_NAME ]"
- "[ $STATIC_FIRST == first_level ]"
- "[ $STATIC_SECOND == first_level ]"
- "[ $STATIC_THIRD == first_level ]"
No Env, top vars:
script:
- set -e
- echo $PREDEF_FIRST
- echo $PREDEF_SECOND
- echo $PREDEF_THIRD
- echo $STATIC_FIRST
- echo $STATIC_SECOND
- echo $STATIC_THIRD
- "[ $PREDEF_FIRST == $CI_PROJECT_NAME ]"
- "[ $PREDEF_SECOND == $CI_PROJECT_NAME ]"
- "[ $PREDEF_THIRD == $CI_PROJECT_NAME ]"
- "[ $STATIC_FIRST == first_level ]"
- "[ $STATIC_SECOND == first_level ]"
- "[ $STATIC_THIRD == first_level ]" In the job CI_ENVIRONMENT_URL, top vars:, variables will not exhibit the bug behavior described below.
In the job No Env, top vars:, variables will exhibit the expected behavior described below.
Example Project
What is the current bug behavior?
Bug behavior is that some subsequent variables set to equal $VARIABLE_NAME get set to explicitly $VARIABLE_NAME instead of the value of the variable
$ echo $LOCAL_PREDEF_FIRST^[[0;m
cdash
$ echo $LOCAL_PREDEF_SECOND^[[0;m
$CI_PROJECT_NAME
$ echo $LOCAL_PREDEF_THIRD^[[0;m
$LOCAL_PREDEF_FIRST
$ echo $LOCAL_STATIC_FIRST^[[0;m
first_level
$ echo $LOCAL_STATIC_SECOND^[[0;m
first_level
$ echo $LOCAL_STATIC_THIRD^[[0;m
$LOCAL_STATIC_FIRST What is the expected correct behavior?
Expected behavior is variables set by value as in:
$ echo $LOCAL_PREDEF_FIRST^[[0;m
cdash
$ echo $LOCAL_PREDEF_SECOND^[[0;m
cdash
$ echo $LOCAL_PREDEF_THIRD^[[0;m
cdash
$ echo $LOCAL_STATIC_FIRST^[[0;m
first_level
$ echo $LOCAL_STATIC_SECOND^[[0;m
first_level
$ echo $LOCAL_STATIC_THIRD^[[0;m
first_level 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)