Make release-tools/deployer/patcher commit file to `gitlab-com` with container image tags as part of deploy
In order to move the gitlab-com
repository towards a pure gitops pattern, as well as making the repository not need to talk to a Kubernetes cluster nor rely on CI environment variables to determine the version to deploy, we want release-tools/deployer to start directly committing a file to the gitlab-com
repo containing the container tags to use for each component.
The reasons we want this done (the problems it solves), and this specific approach to solving them, was discussed in #2455 (closed)
What we want for this first step, is to have release-tools/deployer/patcher do the following
-
Commit a file to the gitlab-com repository, under releases/gitlab/values/versions/${environment}.yaml
path, using the GitLab commit API against GitLab.com -
The contents of the file should look like the following
gitlab:
gitlab-shell:
image:
tag: // tag for gitlab-shell goes here
gitlab-pages:
image:
tag: // tag for gitlab pages goes here
global:
gitlabVersion: // tag for gitlab webservice goes here
-
This will also need to work for the deployment process for pre
environment -
The CI message for the commit should have a link to the CI pipeline that made the change, and have [skip-ci]
at the beginning of the first line -
This should all happen in addition to the triggering of the downstream pipeline with the version number as an environment variable, as normal (for this first step) -
We should have an option for the tooling to instead put the commit directly onto the ops mirror of the gitlab-com
repository, instead of the GitLab.com repo (which will be the default). This is because in a situation where gitlab.com is down, we might need to do a deploy. We can't just always commit to the ops mirror, as that's not the mirror people pull and work from.
Edited by Graeme Gillies