I would like to use a custom variable as branch inside a trigger downstream stage, but it looks like so far that before_script (when I put the variable assignment) is not called before a trigger stage.
That leads to not have the desired branch triggered, because of empty $CUSTOM_VARIABLE.
Basically, this is to trigger the child on a specific TAG name instead of the branch name, if TAG is given...
Here is a sample code showing what I want to do:
default:
before_script:
if [ $CONDITION ];
then
CUSTOM_VARIABLE=$TAG_NAME;
else
CUSTOM_VARIABLE=$CI_COMMIT_REF_NAME;
fi
build:
stage: build
variables:
VAR1: var1
VAR2: var2
trigger:
project: my/child/project
branch: $CUSTOM_VARIABLE
strategy: depend
I also tried to assign the variable conditionally inside variables, but the code is not evaluated and is pasted as it is inside the custom variable.
variables:
CUSTOM_VARIABLE: $([ $CONDITION ] && echo "$TAG_NAME" || echo "$CI_COMMIT_REF_NAME")
Is there a way to use a custom variable as a trigger branch ?
You need to use dotenv
before_script:
if [ $CONDITION ];
then
CUSTOM_VARIABLE=$TAG_NAME;
echo "CUSTOM_VARIABLE=$CUSTOM_VARIABLE" >> build.env
else
CUSTOM_VARIABLE=$CI_COMMIT_REF_NAME;
echo "CUSTOM_VARIABLE=$CUSTOM_VARIABLE" >> build.env
fi
artifacts:
reports:
dotenv: build.env
Related
(How) Can I use variable value as a name for another variable?
I have a job with matrix and dotenv artifacts as follows:
build-names:
stage: build
...
script:
...
<lines omitted>
...
- echo "${NAME}_DEB_PACKAGE_VERSION=${DEB_PACKAGE_VERSION}" >> build.env
artifacts:
reports:
dotenv: build.env
parallel:
matrix:
- NAME:
- name1
- name2
type:
- 0
- 1
environment: $NAME/$TYPE
Then I have a downstream trigger job again using matrix and I want to pass the appropriate package version based on the ${NAME}
build-images:
stage: .post
needs:
- job: build-names
artifacts: true
variables:
PACKAGE_VERSION_VARIABLE_NAME: ${NAME}_DEB_PACKAGE_VERSION
PACKAGE_VERSION: ${${BACKEND_VERSION_VARIABLE_NAME}}
// OR
PACKAGE_VERSION_VARIABLE_NAME: ${NAME}_DEB_PACKAGE_VERSION
PACKAGE_VERSION: ${!BACKEND_VERSION_VARIABLE_NAME}
trigger:
project: group/project-${NAME}
parallel:
matrix:
- NAME:
- name1
- name2
Neither of the two approaches above (double ${${}} or !) works in the variables section.
I could 'generate' the variable within script section, but AFAIK you cannot have both trigger and script within the same job.
Is there a workaround for similar use cases?
(Using self-hosted gitlab 15.4)
I want TEST_VAR to be overridden by the workflow but when I run a $NIGHTLY pipeline, it still prints "normal". What am I doing wrong here? According the the precedence, I believe it should work...
image: alpine
variables:
TEST_VAR: "normal"
workflow:
rules:
- if: $CI_COMMIT_BRANCH
- if: $NIGHTLY
variables:
TEST_VAR: "nightly"
test:
script:
- echo $TEST_VAR
One more option is hack with child pipelines.
nightly-run:
variables:
TEST_VAR: "nightly"
rules:
- if: $NIGHTLY
trigger:
include: .gitlab-ci.yml
strategy: depend
It will override global TEST_VAR if "nightly-run" triggers.
Pay attention all jobs that triggered by "parent pipeline" will with CI_PIPELINE_SOURCE == 'parent_pipeline'.
A solution can be resolve your issus is to update the $TEST_VAR in script part.
script:
- |
- if $NIGHTLY
then
$TEST_VAR = "nightly"
else
$TEST_VAR = "others values"
fi
I need to call a bash script from my gitlab cicd pipeline. When I call it, the input parameter needs to change depending on whether or not this is a merge into master. Basically what I want is this:
if master:
test:
stage: test
script:
- INPUT="foo"
- $(myscript.sh $INPUT)
if NOT master:
test:
stage: test
script:
- INPUT=""
- $(myscript.sh $INPUT)
I'm trying to figure out a way to set INPUT depending on which branch the pipeline is running on. I know there are rules as well as only/except, but they don't seem to allow you to set variable, only test them. I know the brute force way is to just write this twice, one with "only master" and another with "except master", but I would really like to avoid that.
Thanks
I implement this kind of thing using yml anchors to extend tasks.
I find it easier to read and customization can include other things, not only variables.
For example:
.test_my_software:
stage: test
script:
- echo ${MESSAGE}
- bash test.sh
test stable:
<<: *test_my_software
variables:
MESSAGE: testing stable code!
only:
- /stable.*/
test:
<<: *test_my_software
variables:
MESSAGE: testing our code!
except:
- /stable.*/
you get the idea...
Why not have two jobs to run the script and use rules to control when they are ran against master:
test:
stage: test
script:
- if [$CI_COMMIT_REF_NAME == 'master']; then export INPUT="foo"; else INPUT=""; fi
- $(myscript.sh $INPUT)
In gitlab runner, I want to run job by separating branch creation and branch update.
(.yml example)
creat job:
stage: create
script:
- echo 'branch checkout'
only:
- ????
update job:
stage: deply
script:
- echo 'branch update'
only:
- branches
You might be able to check CI_COMMIT_BEFORE_SHA. If it is all zeros, then there is no previous commit for that ref. (It is also all zeros for a merge request.)
See predefined variables.
Here is my simple yaml file
image: my/docker/image
stages:
- print
- testvarbridge
variables:
INCOMING_VAR: $ENV_VAR
print_these:
stage: print
script:
- echo $INCOMING_VAR
- export $INCOMING_VAR
testvarbridge:
stage: testvarbridge
variables:
TEST_VAR: $INCOMING_VAR
trigger:
project: my-project/pipeline-two
branch: ci-cd
the $ENV_VAR is a variable in the project for testing... it just says "this_is_the_variable"
When I trigger the pipleine..the print stage correctly prints:
echo $INCOMING_VAR
this_is_the_variable
But when the second pipeline is triggered, it is just set up to do a simple echo command of the variable that is passed in.. it echo's this:
echo TEST_VAR
$ENV_VAR
As you can see, the when the testvarbridge stage sets up the variable TEST_VAR, it is grabbing the $ENV_VAR variable up top as a literal string. It does not evaluate it and grab the value associated with that variable. Am I missing something?
This was reported 3 years ago in gitlab-org/gitlab-runner issue 1809: "Use variable inside other variable".
A workaround is to set vars in a before_script instead of variables.
So the example given in the issue would work if written as:
before_script:
- export VAR1="${CI_PIPELINE_ID}"
- export VAR2="test-${VAR1}"
Update February 2020: Philippe Charrière adds:
the issue is not closed - the milestone is 13.0 (for May 2020)
Update Sept. 2021,
One last validation is pending and if that's solved then we are shipping this thing in 14.3.
So, soon (14.3, Sept. 2021):
this-job-name-123:
except:
variables:
- $CI_COMMIT_MESSAGE =~ /Skip $CI_JOB_NAME/i
script:
- echo The job runs unless the commit message contains "Skip this-job-name-123"