Skip to content

GitLab Next

delivery
delivery
Closed
Opened by Yorick Peterse@yorickpeterseMaintainer

Monthly releases of Gitaly may use a SHA that isn't deployed, and suffer from a chicken and egg problem when creating stable branches

When releasing Gitaly as part of the monthly release process, the Gitaly stable branch is created from the contents of GITLAB_SERVER_VERSION in GitLab's stable branch for the same release. GitLab in turn updates its GITLAB_SERVER_VERSION file according to the contents of VERSION in Gitaly.

This creates three problems:

  1. When creating stable branches for Gitaly, we may end up using a source SHA that isn't deployed yet. This can happen if GITALY_SERVER_VERSION is updated with a new SHA just before we create a stable branch
  2. When performing a monthly release of GitLab, we update GITALY_SERVER_VERSION according to VERSION in Gitaly. Again, this file may contain a SHA not yet deployed
  3. We can't release without stable branches already existing. This is fine for now as RCs, as tagging an RC creates the stable branch for EE. When we tag an RC, the above version file updates are skipped, and instead we use the file contents as-is.

Solution

When we release a monthly Gitaly release, we update VERSION to the Gitaly version released. GitLab releases re-use that version.

Edited by Amy Phillips
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information