Skip to content

Support for release key in gitlab-ci.yaml

Sean Carroll requested to merge 26013-release-generation-from-within-gitlab-ci-yml-2 into master

What does this MR do?

A new node is added to the gitlab-ci.yaml file to support the creation of Releases. This MR will define the nodes added , validate them and make the parsed configuration available to the pipelines. The code to process the configuration will not be included in this MR.

The Release will only be created if the job is processed without error. If an error is returned from Rails API during Release creation, the release job will fail. There can multiple release jobs in a pipeline

release:
  stage: release
  only: tags
  script:
    - make changelog | tee release_changelog.txt
  release:
    name: Release $CI_TAG_NAME
    tag_name: v0.06
    description: ./release_changelog.txt
    assets:
      links:
        - name: cool-app.zip
          url: http://my.awesome.download.site/1.0-$CI_COMMIT_SHORT_SHA.zip
        - name: cool-app.exe
          url: http://my.awesome.download.site/1.0-$CI_COMMIT_SHORT_SHA.exe

These methods are supported:

  • tag_name - mandatory
  • name - optional
  • description - mandatory
  • assets - optional
  • assets:links:name - optional
  • assets:links:url - mandatory if assets specified

release:tag_name

The tag_name must be specified, and this can either refer to a Git tag or can be specified by the user.

If the $CI_COMMIT_TAG predefined variable is specified as a tag name, it is necessary to also specify only: [tags], otherwise the job will fail when running against branches.

When the specified tag doesn't exist in repository, a new tag will be created from the associated ref of the pipeline. In this case, the tag will point to the latest commit of the ref, instead of the associated SHA of the pipeline.

For example, when creating a Release from a Git tag creation:

job:
  release:
    tag_name: $CI_COMMIT_TAG
    description: changelog.txt
  only:
    - tags

It is also possible to create any unique tag, in which case only: tags is not mandatory. A semantic versioning example:

job:
  release:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
    description: changelog.txt
  • The Release will only be created if the main script of the job succeeded.
  • If the Release already exists it will not update and will cause the job with release keyword to fail.
  • The release section executes after the script tag and before the after_script.

release:name

Specifies the Release name. This is an optional field, if omitted it will be populated with release:tag_name.

release:description

Specifies a file containing the longer description of the Release. This is a mandatory field and can point to a changelog.

release:assets

An array of release:assets:links.

It is possible to add assets to a release, in the form of URLs pointing to an arbitrary external location (such as a S3 bucket or package registry). Any external locations must be populated by a code specified in the script section.

job:
  script:
    - cd src
    - go build hello-world.go
    - make changelog | tee release_changelog.txt
  release:
    name: Release $CI_TAG_NAME
    tag_name: v0.06
    description: release_changelog.txt
    assets:
      - name: hello-world
        url: https://s3.amazonaws.com/myapp_binaries/hello-world

The GitLab Runner will call the GitLab Rails API and create the Release object, adding assets as URLs if defined.

release:assets:links

An array of link entries, optional.

release:
  assets:
    links:
      - name: cool-app.zip
        url: https://downloads.example.org/1.0-$CI_COMMIT_SHORT_SHA.zip

release:assets:links:url

Specifies any valid URL, mandatory if release:assets:links are specified.

release:
  assets:
    links:
      - url: https://downloads.example.org/cool-app.exe

release:assets:links:name

Optional entry. If this is provided, the release:assets:links:url in the same links array element will be displayed using this name, instead of the raw URL.

release:
  assets:
    links:
      - name: cool-app.zip
        url: https://downloads.example.org/1.0-$CI_COMMIT_SHORT_SHA.zip

Tag Only jobs

This functionality has been moved to #118646 (closed)

Feature Flag

This feature will be controlled via a Feature Flag. Refer !19298 (comment 259989805)

Screenshots

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • [-] Label as security and @ mention @gitlab-com/gl-security/appsec
  • [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • [-] Security reports checked/validated by a reviewer from the AppSec team

Part of #26013 (closed)

Edited by Sean Carroll

Merge request reports