Managing and Storing Data, Variables, and Secrets
45%
Order of Precedence for Variables
When you define a variable at the pipeline, job, group, or instance level, you may have variables with the same name at different levels. In this case, GitLab uses the following order of precedence to determine which variable to use in a job (from highest to lowest):
- Project variables <- This is the highest precedence.
- Group variables.
- Instance variables.
- Variables defined in jobs in the
.gitlab-ci.ymlfile (e.g.,$JOB_VARIABLE). - Variables defined in the pipeline in the
.gitlab-ci.ymlfile (e.g.,$PIPELINE_VARIABLE). - Predefined variables (e.g.,
$CI_COMMIT_SHA).
We can see an example of this by creating a .gitlab-ci.yml file that defines a variable at the pipeline level and another variable at the job level:
cat <$HOME/todo/app/.gitlab-ci.yml && \
cd $HOME/todo/app && \
git add . && \
git commit -m "Test variables order of precedence" && \
git push origin main
image: python:3.12
variables:
# Define a global variable
VAR: "I'm a variable defined at the pipeline level"
stages:
- test-variables
test:
variables:
VAR: "I'm Cloud Native CI/CD with GitLab
From Commit to Production ReadyEnroll now to unlock all content and receive all future updates for free.
