> - [Introduced](https://gitlab.com/gitlab-org/release-cli/-/issues/21) in GitLab 13.8.
> - [Changed](https://gitlab.com/gitlab-org/release-cli/-/merge_requests/108): the `release-cli` binaries are also
[available in the Package Registry](https://gitlab.com/jaime/release-cli/-/packages)
starting from GitLab 14.2.
For GitLab Runner shell executors, you can download and install the `release-cli` manually for your [supported OS and architecture](https://release-cli-downloads.s3.amazonaws.com/latest/index.html).
Once installed, the `release` keyword should be available to you.
**Install on Unix/Linux**
1. Download the binary for your system from S3, in the following example for amd64 systems:
when:never# Do not run this job when a tag is created manually
-if:$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH# Run this job when commits are pushed or merged to the default branch
script:
-echo 'running release_job for $TAG'
release:
name:'Release$TAG'
description:'Createdusingtherelease-cli$EXTRA_DESCRIPTION'# $EXTRA_DESCRIPTION and the $TAG
tag_name:'$TAG'# variables must be defined elsewhere
ref:'$CI_COMMIT_SHA'# in the pipeline. For example, in the
milestones:# prepare_job
-'m1'
-'m2'
-'m3'
released_at:'2020-07-15T08:00:00Z'# Optional, is auto generated if not defined, or can use a variable.
assets:
links:
-name:'asset1'
url:'https://example.com/assets/1'
-name:'asset2'
url:'https://example.com/assets/2'
filepath:'/pretty/url/1'# optional
link_type:'other'# optional
```
#### Release assets as Generic packages
You can use [Generic packages](../../user/packages/generic_packages/) to host your release assets.
For a complete example, see the [Release assets as Generic packages](https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs/examples/release-assets-as-generic-package/)
project.
#### `release-cli` command line
The entries under the `release` node are transformed into a `bash` command line and sent
to the Docker container, which contains the [release-cli](https://gitlab.com/gitlab-org/release-cli).
You can also call the `release-cli` directly from a `script` entry.
For example, if you use the YAML described previously:
```shell
release-cli create --name"Release $CI_COMMIT_SHA"--description"Created using the release-cli $EXTRA_DESCRIPTION"--tag-name"v${MAJOR}.${MINOR}.${REVISION}"--ref"$CI_COMMIT_SHA"--released-at"2020-07-15T08:00:00Z"--milestone"m1"--milestone"m2"--milestone"m3"--assets-link"{\"name\":\"asset1\",\"url\":\"https://example.com/assets/1\",\"link_type\":\"other\"}
```
### `secrets`
### `secrets`
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33014) in GitLab 13.4.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33014) in GitLab 13.4.
The `ADDITIONAL_CA_CERT_BUNDLE` value can also be configured as a
[custom variable in the UI](../../../ci/variables/index.md#custom-cicd-variables),
either as a `file`, which requires the path to the certificate, or as a variable,
which requires the text representation of the certificate.
### `release-cli` command line
The entries under the `release` node are transformed into a `bash` command line and sent
to the Docker container, which contains the [release-cli](https://gitlab.com/gitlab-org/release-cli).
You can also call the `release-cli` directly from a `script` entry.
For example, if you use the YAML described previously:
```shell
release-cli create --name"Release $CI_COMMIT_SHA"--description"Created using the release-cli $EXTRA_DESCRIPTION"--tag-name"v${MAJOR}.${MINOR}.${REVISION}"--ref"$CI_COMMIT_SHA"--released-at"2020-07-15T08:00:00Z"--milestone"m1"--milestone"m2"--milestone"m3"--assets-link"{\"name\":\"asset1\",\"url\":\"https://example.com/assets/1\",\"link_type\":\"other\"}
```
### Create multiple releases in a single pipeline
A pipeline can have multiple `release` jobs, for example:
```yaml
ios-release:
script:
-echo 'iOS release job'
release:
tag_name:v1.0.0-ios
description:'iOSreleasev1.0.0'
android-release:
script:
-echo 'Android release job'
release:
tag_name:v1.0.0-android
description:'Androidreleasev1.0.0'
```
### Release assets as Generic packages
You can use [Generic packages](../../packages/generic_packages/index.md) to host your release assets.
For a complete example, see the [Release assets as Generic packages](https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs/examples/release-assets-as-generic-package/)
project.
## Upcoming releases
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38105) in GitLab 12.1.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38105) in GitLab 12.1.
info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Install the `release-cli` for the Shell executor
> - [Introduced](https://gitlab.com/gitlab-org/release-cli/-/issues/21) in GitLab 13.8.
> - [Changed](https://gitlab.com/gitlab-org/release-cli/-/merge_requests/108) in GitLab 14.2, the `release-cli` binaries are also [available in the Package Registry](https://gitlab.com/jaime/release-cli/-/packages).
When you use a runner with the Shell executor, you can download and install
the `release-cli` manually for your [supported OS and architecture](https://release-cli-downloads.s3.amazonaws.com/latest/index.html).
Once installed, [the `release` keyword](../../../ci/yaml/index.md#release) is available to use in your CI/CD jobs.
## Install on Unix/Linux
1. Download the binary for your system from S3, in the following example for amd64 systems:
