Release commands should not rely on release-cli image

Summary

The new releases commands are great to do a release as part of your flow. Without wanting to be offensive, the release-CLI however feels like an bolted-on hack. It basically is a (much better) replacement of the standard 'curling' people are doing. Doing a release (or rather, announcing a release) could be part of any job, regardless of which image is used. As such, the release-cli is probably best served if it is simply part of the standard gitlab-runner image.

Steps to reproduce

Create any job with the 'release' keyword, without the 'release-cli' image.

What is the current bug behavior?

One requires to use the 'release-cli image

What is the expected correct behavior?

The whole idea of the release keyword is fine. But should be able to be used 'anywhere'. If I have a CI file, with 5 jobs, and we produce 3 releases within the various steps (making up something now) by doing:

image: docker
script: docker build && docker push
release: name: "${CI_COMMIT_TAG}-Container"

and then

image: "${CI_COMMIT_TAG}-Container"
script: make && make release
release: name: "${CI_COMMIT_TAG}"

seems logical and sensible?

One more alternative example:

image: remote-uploader
script: ./upload.sh release
release: name: "${CI_COMMIT_TAG}"

The above is interesting, in that all the previous steps may be great and green, and this final step where we upload the assets (regardless of their purpose) to an alternative location and only if this passes, do we announce the release using the releases API.

All of the above seem fine and sensible from a users point of view. Of course there's many technical reasons why things are not this way of course, as a user, I would expect them to behave this way.

Output of checks

This bug happens on GitLab.com

Possible fixes

I believe if release-cli, which is just 'a' implementation to map the release keyword(s) to the release API. As this is all part of the gitlab pipeline, it should be part of the gitlab-runner image. I don't think it's a bad thing to have 2 binaries in the runner image :)

Maybe even have a new repo, gitlab-pipeline-runner for example, that containers the gitlab-runner and the gitlab-release-cli and combines them into a final 'runner' image, if the fear is of cross-pollinating the runner with the release-cli. Have a 'third party' be responsible for the final container of the pipeline runner/worker.