'How does Gitlab-ci triggered subproject evaluate variables in a multiproject pipeline?
Context
- I have a parent (upstream) project with a gitlab ci pipeline
- I have a child (downtream) project with a gitlab ci pipeline
- parent triggers child
- Both parent & child declare a VERSION representing the version of the specific project
Goal
- Parent shall pass its version as CORE_VERSION to child (for reporting purposes)
Issue
Cannot pass variable - that references another variable - from upstream(parent) pipeline to downstream(child) one.
Question
- how can I pass these variables properly?
Details
- parent/upstream project -
CI_COMMIT_SHORT_SHA=09cceef0 - child/downstream project -
CI_COMMIT_SHORT_SHA=c09dcc86 - gitlab-ci of parent
[...]
#
variables:
VERSION: 1.70.$CI_COMMIT_SHORT_SHA
# parent version declaration; value: 1.70.09cceef0
[...]
trigger_childproject:
stage: qa
trigger:
project: childproject
branch: master
strategy: depend
inherit: # only allow propagating these variables
variables:
- CI_COMMIT_BRANCH
- VERSION
variables:
# would like to access upstream project variables using the CORE_ prefix
CORE_VERSION: $VERSION
CORE_BRANCH: $CI_COMMIT_BRANCH
- gitlab-ci.yml of child
[...]
#
variables:
VERSION: 1.70.$CI_COMMIT_SHORT_SHA
# child version declaration; value expected to be: 1.70.c09dcc86
[...]
job_of_child:
stage: test
script: scripts/run-test.sh
- Source of run-test.sh with (
+)Output with (#) Observations
+ Checking out c09dcc86 as master...
[...]
BUILD_REF=${CI_COMMIT_SHORT_SHA:-$(git log --oneline -n1 | grep -Eo '^\w+')}
+ BUILD_REF=c09dcc86
# BUILD_REF has received the child's CI_COMMIT_SHORT_SHA; as expected
VERSION=${VERSION:-"1.0.$BUILD_REF"}
+ VERSION=1.70.09cceef0
# VERSION has received parent project's version
# unexpected, but apparently parent VERSION overrides child declaration
# OK i guess.
[...]
CORE_VERSION=${CORE_VERSION:-?}
+ CORE_VERSION=1.70.c09dcc86
# and this is where it is "messed up"
# The CORE_VERSION - apparently/as far as i can tell - is interpreted as:
# CORE_VERSION: $VERSION # from parent's trigger
# CORE_VERSION=1.70.$CI_COMMIT_SHORT_SHA # VERSION is interpreted as declared in parent
# CORE_VERSION=1.70.c09dcc86 # ie. CI_COMMIT_SHORT_SHA is taken from child
echo ":thumbsup: $TARGET_URL[$CORE_VERSION] QA/diff-hga[$VERSION]: SUCCESS"
+ :thumbsup: parent[1.70.c09dcc86] checked by child[1.70.09cceef0]: SUCCESS
# this is where this whole message is confusing, because parent reports version of child and vice versa :)
Related discussions
Solution 1:[1]
Thanks @sytech for the information.
Reading through the above linked resources, I also ended up with the conclusion: it's an "issue" of how GitLab treats variables; evaluates them; passes them from context to context.
The main issues were
- overlapping variable names - in my case:
VERSION - "recursive" / dynamic definition
My solution
I ended up doing the following
parent-gitlab-ci.yml
# parent / global declaration
variables:
VERSION: 1.70.$CI_COMMIT_SHORT_SHA
[...]
UPSTREAM_CI_COMMIT_BRANCH: $CI_COMMIT_BRANCH
UPSTREAM_CI_COMMIT_SHORT_SHA: $CI_COMMIT_SHORT_SHA
# this still doesn't work properly; but ok; child script relies on UPSTREAM_CI_COMMIT_SHORT_SHA
UPSTREAM_VERSION: $VERSION
[...]
# in the trigger
trigger_pmp-qa:
stage: qa
trigger:
project: child
branch: master
strategy: depend
inherit: # only allow propagating the declared vars
variables:
- UPSTREAM_CI_COMMIT_BRANCH
- UPSTREAM_CI_COMMIT_SHORT_SHA
# this still doesn't work properly; but ok; child script relies on UPSTREAM_CI_COMMIT_SHORT_SHA
- UPSTREAM_VERSION
variables: # plus statically declared vars
SLACK_ENABLED: 'true'
child script
# references UPSTREAM_CI_COMMIT_SHORT_SHA;
# does not see "UPSTREAM_VERSION" because of expansion issues
# but it's ok :smilecry:
CORE_VERSION=${UPSTREAM_VERSION:-1.??.${UPSTREAM_CI_COMMIT_SHORT_SHA:-?}}
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Matyas |
