5. Variables

In GitLab CI/CD, variables can be used to customize jobs by defining and storing values. When using variables there is no need to hard code values. In GitLab, CI/CD variables can be defined by going to Settings –> CI/CD –> Variables or by simply defining them in the .gitlab-ci.yml file.

Variables are useful for configuring third-party services for different environments, such as testing, staging, production, etc. Modify the services attached to those environments by simply changing the variable that points to the API endpoint the services need to use. Also use variables to configure jobs and then make them available as environment variables within the jobs when they run.

As pointed out before, you can define variables in your gitlab-ci.yml. You can reuse this variable within your pipeline across different jobs and stages.

If you want to reuse a variable across different Projects or Groups, you can define them through your GitLab instance (Settings –> CI/CD –> Variables)

In this lab we will talk about the variables in the gitlab-ci.yml file only.

5.1: Define and access custom Variables

To create a custom variable in the .gitlab-ci.yml file, define the variable and value with variables keyword in the top level section.

Global variables can be defined in the variables section:

variables:
  FOO: BAR

You can later reference this variable elsewhere in your .gitlab-ci.yml file. For example

  - echo "Hello Foo ${FOO}"

Output:

hello Foo Bar

5.2: Predefined Variables

There is a set of predefined GitLab Variables which you can reference in your .gitlab-ci.yml script. Each of these variables has the CI_ prefix, such as:

• CI_COMMIT_BRANCH The commit branch name. Available in branch pipelines, including pipelines for the default branch. Not available in merge request pipelines or tag pipelines.
• CI_PROJECT_NAME The name of the directory for the project. For example if the project URL is gitlab.example.com/group-name/project-1, CI_PROJECT_NAME is project-1.
• CI_COMMIT_MESSAGE The full commit message.

Under the following link you can find a full list of all available predefined GitLab variables. https://docs.gitlab.com/ee/ci/variables/predefined_variables.html

Task 5.3: Variables Lab

Define the following two global variables in your .gitlab-ci.yml

• GIT_STRATEGY = clone
• COMPILE = false

The GIT_STRATEGY defines how the git repository is fetched during a pipeline run; valid options are clone, fetch or none. The COMPILE variable disable project compilation and dependency fetching for the security analyser.

stages:
  - info
  - build

variables:
  GIT_STRATEGY: 'clone'
  COMPILE: 'false'

info:
  stage: info
  script:
    - echo "This is your first stage (ツ)"

build_application:
  stage: build
  tags:
    - build
    - mobiliar
  image: registry.access.redhat.com/ubi9/openjdk-17:latest
  script:
    - ./gradlew assemble

Commit and push your changes. Check that the pipeline finishes without problems. The output is the same as in the previous lab.

5.4: Secret and protected Variables

In some cases you need to store sensitive information in a variable. Instead of defining the variable directly in the .gitlab-ci.yml you can create a secret variable in the GitLab project settings.

To add a new secret variable, navigate in the main menu to Settings –> CI/CD –> Variables –> Expand –> Add variable

Flags:

• Protected variable You can protect a project, group or instance CI/CD variable so it is only passed to pipelines running on protected branches or protected tags
• Mask variable You can mask a variable so the value of the variable doesn’t display in job logs.

Task 5.5: Secret and protected Variables Lab

Define following two secret variables in your project

• USERNAME = fooser
• PASSWORD = bassword
  • as a masked variable

Then add a new script line at the end of the info job with following command echo "Username is ${USERNAME} with password ${PASSWORD}"

Run the pipeline again and navigate to the info job log output. You should see the following line

Username is fooser with password [MASKED]

stages:
  - info
  - build

variables:
  GIT_STRATEGY: 'clone'
  COMPILE: 'false'

info:
  stage: info
  script:
    - echo "This is your first stage (ツ)"
    - echo "Username is ${USERNAME} with ${PASSWORD}"

build_application:
  stage: build
  tags:
    - build
    - mobiliar
  image: registry.access.redhat.com/ubi9/openjdk-17:latest
  script:
    - ./gradlew assemble

Commit and push your changes.

How is the protected variable masked in the job log?