Cloud Native CI/CD with GitLab

Tag-based releases in GitLab CI

Releases are a common practice in software development to mark specific points in the project's history, typically associated with version numbers. They often involve packaging the software, generating release notes, and making the release available to users.

In Git, a release is typically driven by a Git tag. A tag represents a fixed point in the repository history and is commonly used to mark versions such as v1.0.0 or v2.3.1.

In GitLab, it can be done from the UI or programmatically using GitLab CI/CD pipelines. When a tag is pushed, GitLab can create a dedicated tag pipeline, which is the natural moment to package, publish, or announce a release.

We usually use the keyword release in the job configuration to define the release process. We also use a special image (registry.gitlab.com/gitlab-org/release-cli:latest) that contains the CLI tool to interact with the GitLab Releases API.

Note that the release keyword will only work if the job is executed in a pipeline triggered by a tag. Therefore, we need to run git tag followed by git push origin --tags or git push origin to create a tag pipeline.

Here is an example:

cat <<'EOF' >$HOME/todo/app/.gitlab-ci.yml && \
git add . && \
git commit -m "Add tag-based release job" && \
git tag v1.0.0 && \
git push origin main v1.0.0
stages:
  - build
  - release

build_job:
  stage: build
  image: python:3.12
  script:
    - pip install -r requirements.txt
  artifacts:
    untracked: true
    expire_in: 1 hour
    exclude:
      - .git/**
      - README.md
      - tests/**
      - .gitlab-ci.yml
      - Dockerfile
      - .dockerignore
      - .gitignore

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  needs:
    - build_job
  rules:
    - if