## Background Currently, we recommend users to use `image: registry.gitlab.com/gitlab-org/release-cli:latest` in their [`release`](https://docs.gitlab.com/ee/ci/yaml/index.html#release) jobs. This image includes the [GitLab Release command-line tool (`release-cli`)](https://gitlab.com/gitlab-org/release-cli) and provides some commands in the "release" job, for example; `release-cli create --name "My Release" --tag_name "1.2.3"`. When a job has the [`release`](https://docs.gitlab.com/ee/ci/yaml/index.html#release) keyword, GitLab [adds a `release` script](https://gitlab.com/gitlab-org/gitlab/-/blob/fcf93c07b325644908c58417422a10f579d1b365/lib/gitlab/ci/build/step.rb#L27) to the job when sending it to Runner ([the script](https://gitlab.com/gitlab-org/gitlab/-/blob/fcf93c07b325644908c58417422a10f579d1b365/lib/gitlab/ci/build/releaser.rb#L7)). Finally, the Runner runs this command and creates a release via [the API](https://docs.gitlab.com/ee/api/releases/#create-a-release). ## Summary Today, we want to add another functionality to `release-cli`; https://gitlab.com/gitlab-org/gitlab/-/issues/442785+. The initial plan was similar to the steps explained the section above. 1. Use `image: registry.gitlab.com/gitlab-org/release-cli:latest`. 2. GitLab -> Runner; `release-cli create --name "My Release" --tag_name "1.2.3"` 3. GitLab -> Runner; `release-cli publish-to-catalog --version "1.2.3"` **new** 4. Runner; [`POST /projects/:id/releases`](https://docs.gitlab.com/ee/api/releases/#create-a-release) 5. Runner; `POST /projects/:id/catalog/publish` **new** We have https://gitlab.com/gitlab-org/release-cli/-/merge_requests/184 and https://gitlab.com/gitlab-org/gitlab/-/merge_requests/167883 for POC. However, we got [the feedback](https://gitlab.com/gitlab-org/release-cli/-/merge_requests/184#note_2140708870) that `release-cli` is being deprecated in favor of [`glab`](https://gitlab.com/gitlab-org/cli) (https://gitlab.com/gitlab-org/cli/-/issues/7450). So, we need to make the changes in `glab` instead. ## Plan 1. [x] Add the `glab` executable in the `release-cli` image so that all new `release-cli:latest` image fetch will include `glab`. https://gitlab.com/gitlab-org/release-cli/-/issues/194 1. [x] Reimplement https://gitlab.com/gitlab-org/release-cli/-/merge_requests/184 into [`glab`](https://gitlab.com/gitlab-org/cli). https://gitlab.com/gitlab-org/gitlab/-/issues/442785. 1. [x] We started supporting to use `CI_JOB_TOKEN` via `glab`: https://gitlab.com/gitlab-org/cli/-/issues/1220. 1. [x] We merged https://gitlab.com/gitlab-org/cli/-/merge_requests/1745, which adds a new feature to the release API. This is not directly related to this effort but we waited for it before releasing a new version of `glab`. GitLab will use `glab release create 3.0.0 --publish-to-catalog` for CI/CD catalog components. https://gitlab.com/gitlab-org/gitlab/-/issues/442785 1. [x] We created a new version of `glab`. https://gitlab.com/gitlab-org/cli/-/releases/v1.50.0 1. [x] We will update the `release-cli` image to include the latest version of `glab`. https://gitlab.com/gitlab-org/release-cli/-/issues/196 1. [x] https://gitlab.com/gitlab-org/cli/-/issues/7450+ Our final goal is that we don't support or recommend `release-cli` anywhere; removing it from documentation, removing [the script](https://gitlab.com/gitlab-org/gitlab/-/blob/fcf93c07b325644908c58417422a10f579d1b365/lib/gitlab/ci/build/releaser.rb#L7), etc. So, in https://docs.gitlab.com/ee/ci/yaml/index.html#release, we'll recommend this instead; ```yaml release_job: image: registry.gitlab.com/gitlab-org/cli:latest # !!This was `release-cli`!! # ... release: # ... ``` The first step in our plan above will help this transition because the users will start to fetch the new `release-cli` image which already includes the `glab` executable. So, we can start removing the `release-cli create` sooner.