Patch release pipeline: Tag patch releases
Context
Currently, during the patch release process, we run these chatops
commands to tag the security/gitlab
to the repo's default branch.
/chatops run release tag --security <patch version>
The command creates and starts a pipeline in release-tools repository, then posts the link of that pipeline in #f_upcoming_release
. We run this chatops
command one patch version at a time.
When we confirm that all the packages and images are successfully built (by checking the dev.gitlab.org pipelines) and confirm that release
environment is running the latest patch version, we run another chatops
command to publish the release. This command is also run one patch version at a time.
Problem Statement
There are a few downsides to having this process using chatops
commands:
- harder to follow and debug, since the process incorporates multiple repositories (chatops, release-tools)
- the links in
#f_upcoming_release
often gets buried during a release process, and gets deleted after slack retention - manual steps for release managers, especially when running the commands one version at a time, waiting for each pipeline to finish in-between. These can be potential steps for human error, and can be difficult to recognize right away.
- can be run out of order -- We should ensure that tagging happens before publishing, also addresses #20079
Migrating to a release-tools pipeline
Recently, we've introduced release-tools
pipelines that are automatically created with patch release task issues, and they get started by release managers during the patch release process. As an example, the pipeline security_release_release_preparation
mentioned here allows the release managers to start the release preparation process by triggering the start
job. Having this process in a pipeline linked to the task issue grants more visibility and discoverability for the process, and scalable for future checks and automation.
This issue is to create a release-tools
pipeline "Patch release tagging pipeline" for tagging the patch releases. This pipeline should:
- Invoke the same rake tasks as the initial
chatops
commands/chatops run release tag --security
- Should have a manual trigger for starting the tagging stage jobs
- This allows the release managers to wait and confirm that EE+CE packages and CNG image are built, and that
release
environment has successfully deployed with the latest patch version, but also - This prevents the publish steps to be run out-of-order, prior to the tagging steps (addressing #20079)
- #20201 (closed) will be worked on after this issue to include the publishing jobs that are dependent on the tagging jobs from this issue.
- This allows the release managers to wait and confirm that EE+CE packages and CNG image are built, and that
- Be created with, and linked in the patch task issue template, and
- Follow the guidelines from https://gitlab.com/gitlab-org/release-tools/-/blob/master/doc/release-pipelines.md
There will be a follow-up issue to automate the checks in-between the stages, and the jobs from that effort may be included as part of this pipeline.
Exit Criteria
-
Pipeline to tag during a patch release gets created and linked with the patch release task issue -
Release managers are instructed on the task issue to use the pipeline, instead of the chatops command