You need to sign in or sign up before continuing.
Create a self-serve registry deployment
The package team is working on container registry more frequently these days which means that the number of changes is growing.
With that grows the need for rolling out changes to our cluster, such as gitlab-com/gl-infra/k8s-workloads/gitlab-com!129 (merged) .
Proposed Solution
- Upon a tag in
gitlab-org/container-registry
, trigger a deploy tok8s-workloads/gitlab-com
- This triggered pipeline will need to receive some information, minimally, the version desired, though we'll need more to ensure the correct pipeline is built.
- The pipeline will perform its deploy, which closes this issue, and sets a precedent for #552
Proposed work
- Modify
k8s-workloads/gitlab-com
to accept information on the registry version and build an appropriate deployment pipeline - Modify
k8s-workloads/gitlab-com
such that it can apply the Container Registry in an idempotent manner, similar to what we did with auto-deploy and sidekiq - Make some form of locking mechanism, such that registry deployments, auto-deploy deployments, etc, do not stomp on top of each other
- This is already a hindrance at times...
- Build out notification capabilities as already described here:
- Add safety checks to validate it is safe to proceed with a deployment at each stage
- This would use metric
gitlab_deployment_health:service
- Currently this does not monitor the registry component so it will need to be added.
- This would use metric
- And finally, something added to
gitlab-org/container-registry
where upon a tag, it'll send a trigger
Edited by John Skarbek