Skip to content

WIP: Release from GitLab CI

Releasing a new Gitaly version is now done by a maintainer. The maintainer executes _support/release to start this process. This process has several downsides, the biggest one is that its invasive of the the workflow of the person releasing. While releasing the worktree should not be touched or a commit be added. It's also harder than ideal to release on dev.gitlab.org, or when developing from a fork. The remote url has to be upgraded first, and requires a few steps to get it right. Last, the release runs all the tests, which is a great feature but shifts burden to a developer, and if a test is broken on their setup its likely it only gets noticed once a release is being created, blocking the release.

This MR is create from my fork, as I wanted to execute the code before merging. !1159 (comment 155200063) proves it worked, the tag is at: https://gitlab.com/zj/gitaly/tags/v123.123.123.

Todo:

  • Get approval of the full team
  • Remove the version v123.123.123 commit from this branch
  • Update documentation of the new flow
  • Upgrade @GitalyBot his permissions to Maintainer
  • Check if @GitalyBot exists on dev.gitlab.org, and has the same permissions
Edited by Zeger-Jan van de Weg

Merge request reports