• View releases
• Create a release
  • Schedule a future release
• Edit a release
• Add release notes to Git tags
• Associate milestones with a release
• Get notified when a release is created
• Prevent unintentional releases by setting a deploy freeze
• Release fields
  • Tag name
  • Release notes description
  • Release assets
    • Permanent links to release assets
  • Source code
  • Links
• Release evidence
  • Collect release evidence
  • Include report artifacts as release evidence
  • Schedule release evidence collection
  • Disable release evidence display
• GitLab Releaser

リリース

GitLab 11.7 で導入されました。

To introduce a checkpoint in your source code history, you can assign a Git tag at the moment of release. However, in most cases, your users need more than just the raw source code. They need compiled objects or other assets output by your CI/CD system.

A GitLab Release is a snapshot of the source, build output, artifacts, and other metadata associated with a released version of your code.

You can create a GitLab release on any branch. When you create a release:

• GitLab automatically archives source code and associates it with the release.
• GitLab automatically creates a JSON file that lists everything in the release, so you can compare and audit releases. This file is called release evidence.
• You can add release notes and a message for the tag associated with the release.

After you create a release, you can associate milestones with it, and attach release assets, like runbooks or packages.

View releases

GitLab 12.8で導入されました。

To view a list of releases:

• Go to Project overview > Releases, or

• On the project’s overview page, if at least one release exists, click the number of releases.

  

  • On public projects, this number is visible to all users.
  • On private projects, this number is visible to users with Reporter permissions or higher.

Create a release

You can create a release in the user interface, or by using the Releases API. We recommend using the API to add release notes as one of the last steps in your CI/CD release pipeline.

To create a new release through the GitLab UI:

1. Navigate to Project overview > Releases and click the New release button.
2. In the Tag name box, enter a name.
3. In the Create from list, select the branch or enter a tag or commit SHA.
4. In the Message box, enter a message associated with the tag.
5. Optionally, in the Release notes field, enter the release’s description. You can use Markdown and drag and drop files to this field.
   • If you leave this field empty, only a tag will be created.
   • If you populate it, both a tag and a release will be created.
6. Click Create tag.

If you created a release, you can view it at Project overview > Releases. If you created a tag, you can view it at Repository > Tags.

You can now edit the release to add milestones and release assets.

Schedule a future release

You can create a release ahead of time by using the Releases API. When you set a future released_at date, an Upcoming Release badge is displayed next to the release tag. When the released_at date and time has passed, the badge is automatically removed.

Edit a release

To edit the details of a release:

1. Navigate to Project overview > Releases.
2. In the top-right corner of the release you want to modify, click Edit this release (the pencil icon).
3. On the Edit Release page, change the release’s details.
4. 変更を保存するをクリックします。

You can edit the release title, notes, associated milestones, and asset links. To change other release information, such as the tag or release date, use the Releases API.

Add release notes to Git tags

If you have an existing Git tag, you can add release notes to it.

You can do this in the user interface, or by using the Releases API. We recommend using the API to add release notes as one of the last steps in your CI/CD release pipeline.

In the interface, to add release notes to a new Git tag:

1. Navigate to your project’s Repository > Tags.
2. Click New tag.
3. In the Release notes field, enter the release’s description. You can use Markdown and drag and drop files to this field.
4. Click Create tag.

In the interface, to add release notes to an existing Git tag:

1. Navigate to your project’s Repository > Tags.
2. Click Edit release notes (the pencil icon).
3. In the Release notes field, enter the release’s description. You can use Markdown in this field, and drag and drop files to it.
4. 変更を保存するをクリックします。

Associate milestones with a release

• GitLab 12.5で導入されました。
• Updated to edit milestones in the UI in GitLab 13.0.

You can associate a release with one or more project milestones.

You can do this in the user interface, or by including a milestones array in your request to the Releases API.

In the user interface, to associate milestones to a release:

1. Navigate to Project overview > Releases.
2. In the top-right corner of the release you want to modify, click Edit this release (the pencil icon).
3. From the Milestones list, select each milestone you want to associate. You can select multiple milestones.
4. 変更を保存するをクリックします。

On the Project overview > Releases page, the Milestone is listed in the top section, along with statistics about the issues in the milestones.

Releases are also visible on the Issues > Milestones page, and when you click a milestone on this page.

Here is an example of milestones with no releases, one release, and two releases, respectively.

Get notified when a release is created

GitLab 12.4で導入されました。

You can be notified by email when a new release is created for your project.

To subscribe to notifications for releases:

1. Navigate to Project overview.
2. Click Notification setting (the bell icon).
3. In the list, click Custom.
4. Select the New release check box.
5. Close the dialog box to save.

Prevent unintentional releases by setting a deploy freeze

GitLab 13.0から導入されました。

Prevent unintended production releases during a period of time you specify by setting a deploy freeze period. Deploy freezes help reduce uncertainty and risk when automating deployments.

Use the Freeze Periods API to set a freeze_start and a freeze_end, which are defined as crontab entries.

If the job that’s executing is within a freeze period, GitLab CI/CD creates an environment variable named $CI_DEPLOY_FREEZE.

To prevent the deployment job from executing, create a rules entry in your gitlab-ci.yaml, for example:

deploy_to_production:
  stage: deploy
  script: deploy_to_prod.sh
  rules:
    - if: $CI_DEPLOY_FREEZE == null

If a project contains multiple freeze periods, all periods apply. If they overlap, the freeze covers the complete overlapping period.

For more information, see Deployment safety.

Release fields

The following fields are available when you create or edit a release.

Tag name

The release tag name should include the release version. GitLab uses Semantic Versioning for our releases, and we recommend you do too. Use (Major).(Minor).(Patch), as detailed in the GitLab Policy for Versioning.

For example, for GitLab version 10.5.7:

• 10 represents the major version. The major release was 10.0.0, but often referred to as 10.0.
• 5 represents the minor version. The minor release was 10.5.0, but often referred to as 10.5.
• 7 represents the patch number.

Any part of the version number can be multiple digits, for example, 13.10.11.

Release notes description

Every release has a description. You can add any text you like, but we recommend including a changelog to describe the content of your release. This helps users quickly scan the differences between each release you publish.

Release assets

You can currently add the following types of assets to each release:

• Source code
• Links

GitLab will support more asset types in the future, including objects such as pre-built packages, compliance/security evidence, or container images.

Permanent links to release assets

GitLab 12.9で導入されました。

The assets associated with a release are accessible through a permanent URL. GitLab will always redirect this URL to the actual asset location, so even if the assets move to a different location, you can continue to use the same URL. This is defined during link creation or updating.

Each asset has a name, a URL of the actual asset location, and optionally, a filepath parameter, which, if you specify it, will create a URL pointing to the asset for the Release. The format of the URL is:

https://host/namespace/project/releases/:release/downloads/:filepath

If you have an asset for the v11.9.0-rc2 release in the gitlab-org namespace and gitlab-runner project on gitlab.com, for example:

{
  "name": "linux amd64",
  "filepath": "/binaries/gitlab-runner-linux-amd64",
  "url": "https://gitlab-runner-downloads.s3.amazonaws.com/v11.9.0-rc2/binaries/gitlab-runner-linux-amd64"
}

This asset has a direct link of:

https://gitlab.com/gitlab-org/gitlab-runner/releases/v11.9.0-rc2/downloads/binaries/gitlab-runner-linux-amd64

The physical location of the asset can change at any time and the direct link will remain unchanged.

Source code

GitLab automatically generates zip, tar.gz, tar.bz2 and tar archived source code from the given Git tag. These are read-only assets.

Links

A link is any URL which can point to whatever you like: documentation, built binaries, or other related materials. These can be both internal or external links from your GitLab instance.

The four types of links are “Runbook,” “Package,” “Image,” and “Other.”

Release evidence

GitLab 12.6 で導入されました。

Each time a release is created, GitLab takes a snapshot of data that’s related to it. This data is saved in a JSON file and called release evidence. It includes linked milestones and issues and can facilitate internal processes like external audits.

To access the release evidence, on the Releases page, click the link to the JSON file that’s listed under the Evidence collection heading.

You can also use the API to generate release evidence for an existing release. Because of this, each release can have multiple release evidence snapshots. You can view the release evidence and its details on the Releases page.

Here is an example of a release evidence object:

{
  "release": {
    "id": 5,
    "tag_name": "v4.0",
    "name": "New release",
    "project": {
      "id": 20,
      "name": "Project name",
      "created_at": "2019-04-14T11:12:13.940Z",
      "description": "Project description"
    },
    "created_at": "2019-06-28 13:23:40 UTC",
    "description": "Release description",
    "milestones": [
      {
        "id": 11,
        "title": "v4.0-rc1",
        "state": "closed",
        "due_date": "2019-05-12 12:00:00 UTC",
        "created_at": "2019-04-17 15:45:12 UTC",
        "issues": [
          {
            "id": 82,
            "title": "The top-right popup is broken",
            "author_name": "John Doe",
            "author_email": "john@doe.com",
            "state": "closed",
            "due_date": "2019-05-10 12:00:00 UTC"
          },
          {
            "id": 89,
            "title": "The title of this page is misleading",
            "author_name": "Jane Smith",
            "author_email": "jane@smith.com",
            "state": "closed",
            "due_date": "nil"
          }
        ]
      },
      {
        "id": 12,
        "title": "v4.0-rc2",
        "state": "closed",
        "due_date": "2019-05-30 18:30:00 UTC",
        "created_at": "2019-04-17 15:45:12 UTC",
        "issues": []
      }
    ],
    "report_artifacts": [
      {
        "url":"https://gitlab.example.com/root/project-name/-/jobs/111/artifacts/download"
      }
    ]
  }
}

Collect release evidence

When a release is created, release evidence is automatically collected. To initiate evidence collection any other time, use an API call. You can collect release evidence multiple times for one release.

Evidence collection snapshots are visible on the Releases page, along with the timestamp the evidence was collected.

Include report artifacts as release evidence

When you create a release, if job artifacts are included in the last pipeline that ran, they are automatically included in the release as release evidence.

Although job artifacts normally expire, artifacts included in release evidence do not expire.

To enable job artifact collection you need to specify both:

1. artifacts:paths
2. artifacts:reports

ruby:
  script:
    - gem install bundler
    - bundle install
    - bundle exec rspec --format progress --format RspecJunitFormatter --out rspec.xml
  artifacts:
    paths:
      - rspec.xml
    reports:
      junit: rspec.xml

If the pipeline ran successfully, when you create your release, the rspec.xml file is saved as release evidence.

Schedule release evidence collection

GitLab 12.8で導入されました。

In the API:

• If you specify a future released_at date, the release becomes an Upcoming Release and the evidence is collected on the date of the release. You cannot collect release evidence before then.
• If you use a past released_at date, no evidence is collected.
• If you do not specify a released_at date, release evidence is collected on the date the release is created.

Disable release evidence display

The :release_evidence_collection feature flag is enabled by default in GitLab self-managed instances. To turn it off, ask a GitLab administrator with Rails console access to run the following command:

Feature.disable(:release_evidence_collection)

GitLab Releaser

GitLab Releaser is a CLI tool for managing GitLab Releases from the command line or from GitLab’s CI/CD configuration file, .gitlab-ci.yml.

With it, you can create, update, modify, and delete releases right through the terminal.

Read the GitLab Releaser documentation for details.