Proposal: Deprecate release-cli in favor of glab

Current Situation

The groupenvironments currently owns (and "should" maintain) the release-cli.

For those who don't know: the release-cli is a standalone Go CLI tool that can be used to get, create and update a GitLab Release. It's most prominently used with the release entry in GitLab pipelines. The release keyword merely translates it's entries into a shell command that invokes release-cli. For the GitLab pipelines, the release-cli project also deploys a container image that is used in Ci jobs using the release keyword.

In the groupenvironments team we currently have the "issue" that the release-cli was inherited when the former groupconfigure [DEPRECATED] and grouprelease [DEPRECATED] teams have been merged. In todays groupenvironments there are no engineers left that used to maintain the release-cli - though they are still active there (huge thanks to them 🤝). Nonetheless, the groupenvironments should still be able to maintain the tool and the groups metrics are affected by e.g. typebug.

The GitLab CLI (glab) already supports the get (it's called view here) and the create commands and is only missing the update command.

Proposal

My goal would be to eventually deprecate the release-cli CLI tool (not the entire release-cli project, which e.g. also includes the Dockerfile).

I think we could make this work by:

1. Implement the missing functionality that release-cli supports in glab - that is, the update command.
2. Implement a small release-cli wrapper (in shell script, Go, whatever) in the release-cli project that has the same backwards-compatible interface as the current release-cli, e.g. reading defaults from environment variables and general command interface.
3. Deploy a container image with the aforementioned wrapper and glab and make the change transparent to the users of the release-cli, including pipeline users.

At a later point in the future we could think about deprecating the entire release-cli project and point users to using a glab container image in their pipeline jobs and call glab directly when using the release keyword in the pipeline. But that, can be discussed later and separately. It's not the point of this issue as this would be a breaking change.

Impact

Pros:

• We (GitLab) don't need to maintain two feature sets (get, create and update) releases via CLI in two different tools.
• release-cli uses custom made GitLab API-related code, whereas in glab we can benefit from the infrastructure around using go-gitlab.
• More users for glab (also Dogfooding) which would also better battle test the anyways available Releases-related commands.
• One CLI tool to interact with all-things GitLab.
• ... ?

Cons:

• MAYBE: the release-cli contains more than it has to (entire glab).
• ... ?