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
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:
- Implement the missing functionality that
release-cli
supports inglab
- that is, the update command. - Implement a small
release-cli
wrapper (in shell script, Go, whatever) in therelease-cli
project that has the same backwards-compatible interface as the currentrelease-cli
, e.g. reading defaults from environment variables and general command interface. - 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 inglab
we can benefit from the infrastructure around usinggo-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 (entireglab
). - ... ?