GitLab 11.7 introduces Releases to create release entries (much like GitHub), including release assets. Releases are attached to an existing Git tag, so make sure the Git part is configured correctly.
GitLab releases work just like GitHub releases:
- Configure
gitlab.release: true
. - Obtain a personal access token (release-it only needs the "api" scope).
- Make sure the token is available as an environment variable. Example:
export GITLAB_TOKEN="f941e0..."
GitLab Releases do not support pre-releases or drafts.
By default, the output of git.changelog
is used for the GitLab release notes. This is the printed Changelog: ...
when release-it boots. Override this with the gitlab.releaseNotes
option. This script will run just before the actual
GitLab release itself. Make sure it outputs to stdout
. An example:
{
"gitlab": {
"release": true,
"releaseNotes": "generate-release-notes.sh ${latestVersion} ${version}"
}
}
For GitLab 11.6 and lower, a GitLab Release means release-it will automatically fall back to attach releases notes to a tag. In this case, assets will not get included.
To upload binary release assets with a GitLab release (such as compiled executables, minified scripts, documentation),
provide one or more glob patterns for the gitlab.assets
option. After the release, the assets are available to
download from the project's releases page. Example:
{
"gitlab": {
"release": true,
"assets": ["dist/*.dmg"]
}
}
The origin
can be set to a string such as "http://example.org:3000"
to use a different origin from what would be
derived from the Git url (e.g. to use http
over the default https://${repo.host}
).