Proposal for new release process

Gitaly has a release process which diverts from GitLab-Rails, mostly as releases are created much more often to allow for faster integration of features into the main project, which is dependent on GITALY_SERVER_VERSION. The dependency also influences the way Gitaly does security releases as Gitaly must tag a release early to allow the Rails test suite to run against a new Gitaly version. This creates a window where a tag will exist on dev.gitlab.org, but not on gitlab.com. Potentially blocking normal patch releases as tags are created from the X-Y-stable branches. Another dependency, is that GitLab as a company is open by default. Gitaly is developed at gitlab.com, unless the code is fixing an existing security problem. In that case dev.gitlab.org is used. Developers now have to take extra care manually not to push to the wrong remote. The release process could be updated on several fronts, but most important is the security process. However, given these processes are tied to one another, the full process needs to be changed.

Proposed release process

Ideally, any Gitaly maintainer would run /chatops run gitaly-release v1.50.0 for a release from the default branch, tagged as v1.50.0. Which would perform the following steps in a CI job:

1. Clone the repository from dev.gitlab.org
2. Add a remote for gitlab.com, and fetch all the data
3. Check for both dev.gitlab.org and gitlab.com if the tag already exists
4. Check if the source branch for both remotes dereference to the same commit
5. For the commit, check if the pipeline on the source branch was successful
6. Generate the changelog
7. Create a tag leveraging the GitLab API on gitlab.com

• Push mirroring will be triggered and sync the tag to dev.gitlab.org

In the case of security releases the following flags are passed --security and --source-branch=. The security flag makes sure the tag isn't pushed to .com, but to dev.gitlab.org. The source branch, if passed, would tag against the commit the branch dereferences to. If not passed it defaults to master.

Triggering by chatops allows us to reuse logic that is being used for releasing GitLab and now being maintained in https://gitlab.com/gitlab-org/release-tools. That would remove release logic from this repository. This removes some flexibility for the team, although being more inline with other teams processes shifts the burden of maintenance to a shared responsibility.