Patch release pipeline: Publish patch releases
Context
Currently, during the patch release process, we run these chatops
commands to publish the release, one patch version at a time. We do this after the tagging process.
/chatops run publish --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.
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 add onto the release-tools
pipeline "Patch release tagging and publishing pipeline" (created in #20191 (closed)) to have jobs to publish the release, only after tag has been run. This pipeline should:
- Invoke the same rake tasks as the initial
chatops
commands/chatops run publish --security
, - Have a manual trigger for starting the publishing 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)
- This allows the release managers to wait and confirm that EE+CE packages and CNG image are built, and that
- Be 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
-
The pipeline to tag and publish 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