i know a bout the different scopes and gotchas of variable resolution in the different CI constructs but this one still caught me by surprise:
when defining a global variable like so:
variables: TARGET_BRANCH: $CI_COMMIT_BRANCH
TARGET_BRANCH is not resolved to the branch name (at least) in these constructs:
rules: #this is a global rule! - if: '$TARGET_BRANCH == dev ' job: environment: $TARGET_BRANCH
Note, that when hard coding the TARGET_BRANCH in the global var section that the value can be queried.
I would have posted this as a bug but was asked by the template to go here for a discussion 1st.
While here, i here i was musing over that fact that gitlab is plagued by a very inconsistent/in transparent mechanism for variable resolution. My gut feeling is that this got to the state thru organic growth (ie not designed).
What i would like to have in the docs somewhere is a matrix of
- which scopes of variables exist
- which predefined vars are available when and in which scopes
- when vars are expanded/resolved, this might depend on where they are defined
- when what var may get overridden where
Having this matrix doc, i feel the dev/design team would be able to deliver a more robust and less surprising behavior.