Specify that a merge request should create a tag when merged
Problem to solve
We manage the release process for a number of GitLab projects with merge requests. For example, this MR today in gitlab-workhorse: gitlab-workhorse!352 (merged). Once the MR is merged, we always create a new tag on the merge commit with values derived from a few simple rules. This is a fairly error-prone process, although we have some tiny scripts to try to minimize the effort / risk
Target audience
Developers, reviewers, release managers
Further details
The tag we want to create is usually determined by the changes we make in the VERSION and CHANGELOG, which is what actually gets reviewed. Post-merge, the maintainer must manually create the tag, and do so without error. This step is not subject to any review, and it's not unheard of for a maintainer to push a bad tag. Once published, it is not generally safe to remove a tag, so mistakes of this nature have high overhead.
Proposal
Allow a merge request to include a "tag creation request" of some sort. This can be filled in by the author and reviewed as part of the normal code review cycle. Upon merge, the tag is automatically created by GitLab.
A further application of this feature could come from dependent/group merge requests, per https://gitlab.com/gitlab-org/gitlab-ce/issues/55030 - in the workhorse, gitaly, gitaly-proto, gitlab-pages, etc, cases, we have one merge request in the satellite project, then a small MR in gitlab-ce that bumps a version number. That version number is only relevant - and the merge to gitlab-ce is only valid - when the tag actually exists, and the tag can't be created until the MR has been merged. So any functionality that looks to automate merging several MRs at once, or in a particular order, would benefit from this functionality.
What does success look like, and how can we measure that?
As a gitlab-workhorse maintainer, I can cut a new workhorse release simply by merging an MR prepared for me by a contributor.