{"id":12272,"date":"2022-02-11T16:07:08","date_gmt":"2022-02-11T16:07:08","guid":{"rendered":"https:\/\/mailinvest.blog\/index.php\/2022\/02\/11\/how-to-set-variables-in-your-gitlab-ci-pipelines-cloudsavvy-it\/"},"modified":"2022-02-11T16:07:08","modified_gmt":"2022-02-11T16:07:08","slug":"how-to-set-variables-in-your-gitlab-ci-pipelines-cloudsavvy-it","status":"publish","type":"post","link":"https:\/\/mailinvest.blog\/index.php\/2022\/02\/11\/how-to-set-variables-in-your-gitlab-ci-pipelines-cloudsavvy-it\/","title":{"rendered":"How to Set Variables In Your GitLab CI Pipelines \u2013 CloudSavvy IT"},"content":{"rendered":"

<\/a>\n<\/p>\n

\n

\"Graphic<\/p>\n

GitLab CI\u2019s Variables system lets you inject data into your CI job environments. You can use variables to supply config values, create reusable pipelines, and avoid hardcoding sensitive information into your .gitlab-ci.yml<\/code> files.<\/p>\n

In this guide we\u2019ll look at how you can set and use variables within your own CI system. There are several options available depending on where you want values to be surfaced and how regularly you\u2019ll want to change them.<\/p>\n

The Basics<\/h2>\n

At their simplest variables are key-value pairs which are injected as environment variables into your pipeline\u2019s execution context. You can reference them within your .gitlab-ci.yml<\/code> file as standard environment variables:<\/p>\n

\n
\n
\n
\n
\n
\n
\n
test<\/span>:\n  script<\/span>:\n<\/span>    - echo \"$EXAMPLE_VARIABLE\"<\/span><\/pre>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
You can escape the $<\/code> character using the $$VARIABLE<\/code> syntax:<\/p>\n
\n
\n
\n
\n
\n
\n
\n
test<\/span>:\n  script<\/span>:\n<\/span>    - echo \"$$EXAMPLE_VARIABLE\"<\/span><\/pre>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
This example would cause $EXAMPLE_VARIABLE<\/code> to be logged, instead of the value<\/em> of the EXAMPLE_VARIABLE<\/code> variable as shown above.<\/p>\n
Variables are available within the job\u2019s environment. They can also be interpolated into the values of other fields in your .gitlab-ci.yml<\/code> file, enabling dynamic pipeline configuration:<\/p>\n
\n
\n
\n
\n
\n
\n
\n
build<\/span>:\n  image<\/span>: <\/span>$CI_REGISTRY_IMAGE\/build-utils:latest<\/pre>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
GitLab CI defines several built-in variables<\/a> that are always available. These include details of the commit, branch, and merge request that the pipeline\u2019s running against. The predefined variables also provide access to per-job credentials for accessing other GitLab features such as the Container Registry<\/a> and Dependency Proxy<\/a>.<\/p>\n
Beyond these built-in variables, you can set your own values in multiple places. Variables are supported at the instance, group, project, and pipeline level, giving you flexibility when setting fallback values, defaults, and overrides. You can set variables using the GitLab UI or the API<\/a>; we\u2019re concentrating on the UI in this guide.<\/p>\n
Defining a Variable<\/h2>\n
Variables are created on the Settings > CI\/CD > Variables screen of the scope you want them to be available in. For a project-level variable, that means going to Settings > CI\/CD from GitLab\u2019s left sidebar while viewing a page within the project. Similarly, for group-level variables, navigate to the group and use the sidebar to reach its CI settings. Instance-level variables are located via the same route in the GitLab Admin Area.<\/p>\n
Expand the \u201cVariables\u201d section to view any variables that have already been defined. Click the blue \u201cAdd variable\u201d button to begin adding a new item to the list.<\/p>\n
\"\"<\/p>\n
Each variable needs a unique Key; this is how you\u2019ll reference the variable within your pipeline and its scripts. The name you choose must be compatible with the shell that\u2019ll run your job \u2013 if you pick a reserved keyword, your job could fail. All variables should be a valid string containing only alphanumeric characters and underscores.<\/p>\n
Next set the value of your variable. When the \u201cType\u201d dropdown is left at \u201cVariable,\u201d this value will be injected as-is each time you reference the variable in your pipeline. Changing the type to \u201cFile\u201d will inject the value as a temporary file in your build environment; the value of the environment variable will be the path to that temporary file. This can be a safer way to inject sensitive data if your application is prepared to read the final value from the specified file.<\/p>\n
\"\"<\/p>\n
Once you\u2019re done, click the green \u201cAdd variable\u201d button to complete the process. You can now reference your variable in pipelines that execute within the scope you defined it in. For a project variable, it\u2019ll be defined for pipelines inside that project, whereas instance-level variables will be available to every pipeline on your GitLab server.<\/p>\n
Variables can be managed at any time by returning to the settings screen of the scope they\u2019re set in. Click the Edit button (pencil icon) next to any variable to display the editing dialog and change the variable\u2019s properties. This dialog also provides a way to delete redundant variables.<\/p>\n
Protected Variables<\/h3>\n
Variables can be marked as \u201cprotected\u201d by selecting the checkbox in the \u201cadd variable\u201d dialog. This option means the variable will only be defined in pipelines running against protected branches or tags.<\/p>\n
Protected variables are ideal in circumstances where you\u2019re exposing a sensitive value such as a deployment key that won\u2019t be used in every pipeline. Limiting that value to only the pipelines that actually need it (like deployment jobs running against your protected release<\/code> branch) lowers the risk of accidental leakage.<\/p>\n
Masked Variables<\/h3>\n
The \u201cMask variable\u201d option is another way to enhance the safety of your variables. When this checkbox is enabled, GitLab will automatically filter the variable\u2019s value out of collected job logs. Any unintentional echo $SECRET_VALUE<\/code> will be cleaned up, reducing the risk of a user seeing a sensitive token value as they inspect the job logs using the GitLab web UI.<\/p>\n
Successful masking requires variable values to be reliably detectable within the logs. Consequently it only works for values that meet specific formatting requirements<\/a>. Most common authentication token formats, as well as all Base64-encoded data, will be compatible. Masking only works for values up to 4 KiB in size.<\/p>\n
Environment-Level Variables<\/h3>\n
Variables can be assigned to specific environments<\/a>. This feature lets your pipelines operate with different configuration depending on the environment they\u2019re deploying to.<\/p>\n
Use the \u201cEnvironment scope\u201d dropdown in the \u201cAdd variable\u201d dialog to select an environment for your variable. The variable will only be defined in pipelines which reference the selected environment via the environment<\/code> field in the .gitlab-ci.yml<\/code> file.<\/p>\n
Setting Variables In .gitlab-ci.yml<\/code><\/h2>\n
Variables can be defined within your .gitlab-ci.yml<\/code> file using a variables<\/code> block<\/a>. Variables listed here will be created for the job if they don\u2019t already exist; otherwise, they\u2019ll override the value set at the project-level or higher.<\/p>\n
Variables can be set at the pipeline level with a global variables<\/code> section. Individual jobs can have their own variables too. Both approaches are shown below where the staging job overrides the value of a pipeline-level variable and sets a unique job-specific variable in addition.<\/p>\n
\n
\n
\n
\n
\n
\n
\n
variables<\/span>:\n  DEPLOY_URL<\/span>: <\/span>example.com\n\ndeploy_staging<\/span>:\n  variables<\/span>:\n    DEPLOY_URL<\/span>: <\/span>staging.example.com\n    DEPLOY_IS_STAGING_ENV<\/span>: <\/span>true\n  script<\/span>:\n<\/span>    - .\/deploy.sh\n\ndeploy_production<\/span>:\n  script<\/span>:\n<\/span>    - .\/deploy.sh<\/pre>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
Variables defined in .gitlab-ci.yml<\/code> files can sometimes be used in different ways to those set within the GitLab UI or API. You might use a variable to avoid repeating sections of the file, even if those values aren\u2019t likely to change or be overridden in the future. Hence variables<\/code> sections can feel closer to the variables of programming languages than the config-like keys commonly found at the project level and higher.<\/p>\n
Overriding Variables<\/h2>\n
GitLab\u2019s variable system gives you multiple points at which you can override a variable\u2019s value before it\u2019s fixed for a pipeline or job. The precedence order<\/a> is relatively complex but can be summarized as the following:<\/p>\n