The Gitlab documentation shows how to use a ‘dotenv’ artifact to pass values from one job to another in a CI/CD pipeline. In this article, I want to show an example of this method, but also another method using a custom artifact.
dotenv artifact for passing variable between jobs
Here is how a variable set in ‘job-dotenv-write’ can be read in a job named ‘job-dotenv-read’.
# write variable to dotenv artifact that can be used in another job
job-dotenv-write:
script: |
echo "PASS_THIS_VAR=created in job1" >> build.env
artifacts:
reports:
dotenv: build.env
# use dotenv artifact from other job
job-dotenv-read:
needs: [ "job-dotenv-write" ]
script: |
echo "(read from dotenv) PASS_THIS_VAR = $PASS_THIS_VAR"
The ‘artifacts.reports.dotenv‘ persists the variable, which is then available to other jobs. We explicitly defined the ‘needs’ dependency in this example (as opposed to ordering the jobs using stages), if not defined it would download all artifacts from previous jobs.
Custom artifact for passing variable between jobs
If the dotenv scope exposes values too widely OR you want the ability to use the actual file in another job, you can pass values using a custom artifact. In the example below, we write a variable to a “custom.env” file in the ‘job-custom-env-write’ job, then explicitly source it from the ‘job-custom-env-read’ job.
# write variable to custom.env artifact that can be used in another job
job-custom-env-write:
script: |
echo "CUSTOM_VAR1=abc123" > custom.env
artifacts:
paths:
- custom.env
# use dotenv artifact AND custom.env artifact from other job
job-custom-env-read:
needs: [ "job-dotenv-write", "job-custom-env-write" ]
before_script: |
# directly access the custom.env file created in another job
ls -l $CI_PROJECT_DIR
[ -f custom.env ] && source custom.env
script: |
echo "(read from dotenv) PASS_THIS_VAR = $PASS_THIS_VAR"
echo "(read from custom.env) CUSTOM_VAR1 = $CUSTOM_VAR1"
The ‘artifacts.paths‘ persists the variable, which is then available to other jobs that explicitly source the file. We explicitly defined the ‘needs’ dependency in this example (as opposed to ordering the jobs using stages), if not defined it would download all artifacts from previous jobs.
Notice that “custom.env” is directly available to us on the filesystem, for whatever purposes we choose. Whereas the dotenv artifact is sourced into the environment, but not available for access.
REFERENCES
gitlab.com, pass environment variable to another job
gitlab.com, workflow rules and setting variables within workflow section
stackoverflow, how to assign output to a variable in GitLab CI
gitlab docs, default stages (.pre, build, test, deploy, .post)