How do component version files work with self-serve deployments
Problem Statement
Currently, gitlab-org/gitlab
maintains a knowledge of the version of components that exist outside the project (registry, pages, gitaly, KAS et al) via version files that contain either a tag or a commit SHA (e.g. GITALY_SERVER_VERSION
and GITLAB_KAS_VERSION
). These version files are considered authoritative, though different components have different methods of updating those version files. In a self-serve model, where each component could be running their own deployment pipeline, what happens to these version files? How do we coordinate between self-serve pipelines and ensuring that gitlab-org/gitlab
knows which version of which component it should contain? What does this mean for self-managed?
Possible Implementations
- We leave as-is and continue to require the VERSION files to be updated in the same fashion they are today. This introduces risk if .com is very ahead and a version bump is missed when we begin cutting a release.
- We modify release-tools to know a component has it's own auto-deploy, and we instead query what is the latest version successfully deployed and not rolled back that can update the VERSION file when we tag.
- We remove VERSION files entirely and shift that knowledge to an external SSOT in something like a manifest that describes any given versioned release of .com or self-managed and the versions of the components that it contains