Cloud Native CI/CD with GitLab

Limitations and Pitfalls

Rules, Workflows and other GitLab features, in combination with predefined variables, can be used to make your pipelines more efficient, readable, maintainable and flexible. However, there are some pitfalls you should be aware of.

For example, not all predefined variables are available in all versions of GitLab. So while, variables like CI_BUILDS_DIR and CI_PIPELINE_TRIGGERED are available in all versions, CI_MERGE_REQUEST_DESCRIPTION and CI_MERGE_REQUEST_DESCRIPTION_IS_TRUNCATED are only available in GitLab 16.7 and 16.8, respectively. The same applies to the runner version you are using. Some variables are only available in newer versions of the runner.

You should also read the description of the variable and make sure it works in your specific case. To illustrate this with an example, let's imagine the following scenario: Imagine you use feature branches to develop new features. You may create tags for each feature branch to reference your code at a specific point in time. However, you want to create a release only when a tag is created on the main branch. In this case, you can use the rules keyword to include or exclude jobs based on conditions. This is how it could be done initially:

• We have two stages, build and release.
• The release_job job runs only when a tag that point to a commit on the main branch.
• The release_job job uses the predefined variable CI_COMMIT_TAG to get the tag name

stages:
  - build
  - release

build_job:
  stage: build
  image: python:3.12
  script:
    - pip install -r requirements.txt
  artifacts:
    # Include all files in the build directory
    # including the untracked files 
    # (e.g., those in .gitignore)
    untracked: true

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  dependencies:
    -