docs.gitlab.com release 15.2 (July, 2022)
Tasks for all releases
Documentation for handling the docs release is available.
Between the 17th and 20th of each month
-
Cross-link to the main MR for the release post: gitlab-com/www-gitlab-com!107227 (merged) -
Monitor the #releases
Slack channel. When the announcementThis is the candidate commit to be released on the 22nd
is made, it's time to begin. -
Create a stable branch and Docker image for release. Do not create a merge request, just push the stable branch. -
Verify that the image:docs-single
job passed in the new pipeline, and created a Docker image tagged with the name of the branch. (If it fails, how do I fix it?)
-
-
Create a release merge request for the new version, which updates the version dropdown menu for all online versions, updates the archives list, and adds the release to the Docker configuration. -
Mark as Draft
and do not merge. -
Check the review app to make sure the Versions menu displays correctly.
-
After the tasks above are complete, you don't need to do anything for a few days.
On the 22nd, or the first business day after
After release post is live on the 22nd, or the next Monday morning if the release post happens on a weekend:
-
Merge the release merge requests and run the necessary Docker image builds. -
Merge the MRs for updates to the dropdown menus. (The ones Evan created) -
Are all pipelines green? -
Merge the docs-release merge request for 15.2. -
Go to the scheduled pipelines page and run the Build Docker images weekly pipeline. -
In the scheduled pipeline you just started, manually run the image:docs-latest
job that builds the:latest
Docker image. -
When the pipeline is complete, run the Build docs.gitlab.com every 4 hours
scheduled pipeline to deploy all new versions to the public documentation site. No manually-run jobs are needed for this second pipeline.
-
-
After the deployment completes, open docs.gitlab.com
in a browser. Confirm both the latest version and the correct pre-release version are listed in the documentation version dropdown. -
Check all published versions of the docs to ensure they are visible and that their version menus have the latest versions. -
In this issue, create separate threads for the retrospective, and add items as they appear: ## :+1: What went well this release?
## :-1: What didn’t go well this release?
## :chart_with_upwards_trend: What can we improve going forward?
-
Mention @gl-docsteam
and invite them to read and participate in the retro threads.
After the 22nd of each month:
-
Create a release issue for the next TW and assign it to them. -
Major releases only. Update OutdatedVersions.yml with the newly-outdated version. -
Improve this checklist. Continue moving steps from releases.md
to here until the issue template is the single source of truth and the documentation provides extra information.
Helpful links
Edited by Suzanne Selhorn