Gitlab - Release

GitLab release functionality is flexible, able to be configured to match your workflow.

• Introducció
• Glab
• Creating a release by using a CI/CD job
• Generic Package
• Permanent link
• Git Tag

Introducció

Create a release to package your project at critical milestones. Releases combine code, binaries, documentation, and release notes into a complete snapshot of your project. When a release is created, GitLab automatically tags your code, archives a snapshot, and generates audit-ready evidence. This creates a permanent record that’s perfect for compliance requirements and can give your users confidence in your development process

Gitlab - Release

Glab

glab release

Crea un projecte test-release amb Gitlab - Glab

glab repo create test-release
cd test-realease

Crea un “release” de manera interactiva

glab release create 0.0.1

Create a release non-interactively by specifying a note

glab release create 0.0.2 --notes "Hello World!"

Creating a release by using a CI/CD job

You can create a release directly as part of the GitLab CI/CD pipeline by using the release keyword in the job definition. You should likely create a release as one of the last steps in your CI/CD pipeline.

The release is created only if the job processes without error. If the API returns an error during release creation, the release job fails.

To authenticate your installation of glab with a CI job token, the glab command must be run in a GitLab CI job.

The token is automatically provided by the GitLab Runner via the CI_JOB_TOKEN environment variable.

glab auth login --job-token $CI_JOB_TOKEN --hostname $CI_SERVER_HOST --api-protocol $CI_SERVER_PROTOCOL
GITLAB_HOST=$CI_SERVER_URL glab release list -R $CI_PROJECT_PATH

Endpoints allowing the use of the CI job token are listed in the GitLab documentation.

Tens un exemple a: https://gitlab.com/xtec/kotlin/compose-composition/-/blob/main/.gitlab-ci.yml

Generic Package

Gitlab - Release assets as Generic packages

You can use Generic packages to host your release assets. For a complete example, see the Release assets as Generic packages project.

Below is a complete example that generates release assets, publishes them as a Generic package, and then creates a release:

Use Gitlab - Glab CLI.

release_job:
    stage: release
    image: registry.gitlab.com/gitlab-org/cli:latest
    rules:
        - if: $CI_COMMIT_TAG
    script:
        - echo "Running the release job."
    release:
        tag_name: $CI_COMMIT_TAG
        name: 'Release $CI_COMMIT_TAG'
        description: 'Release created using the cli.'

Permanent link

Gitlab - Permanent link to latest release

Git Tag

Tagging commit with meaningful version number like major.minor.patch (see Semantic Versioning 2.0.0 | Semantic Versioning) is a common way to name a source tree.

Annotated tag is like a “heavyweight” tag, meaning that like a commit they also include a message and an author. IMHO, they also are a perfect way to mark the importance of version number and to isolate them from lightweight tag.

git tag -a 0.0.2 -m ":version: 0.0.2"

Push the tag upstream to GitLab: git push origin 0.0.2.

git push origin 0.0.2

The tag is now visible on the project’s tag page, and the upload and release jobs are triggered.

On pipeline completion, you can see the release on the project’s releases page.

git push --follow-tags

Repository tags

For version as git tag: use annotated tag, not ‘v’ prefix