docs.gitlab.com release 15.6 (November, 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!114276 (merged) (Need help finding the MR?) -
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: -
In the root path of the gitlab-docs
repository, update your local clone:make update
-
Run the Rake task to create the single version. For example, to create the 15.0 release branch and perform other tasks: ./bin/rake "release:single[15.0]"
A branch for the release is created, a new
15.0.Dockerfile
is created, and.gitlab-ci.yml
has branches variables updated into a new branch. These files are automatically committed. -
Push the newly created branch, but don't create a merge request. After you push, the
image:docs-single
job creates a new Docker image tagged with the name of the branch you created earlier. Go to theregistry
environment at https://gitlab.com/gitlab-org/gitlab-docs/-/environments/folders/registry and confirm the image is listed. Theimage:docs-single
might fail initially because often not all stable branches are created yet. Some of the stable branches are created close to the 22nd, which will resolve most issues when you follow the rest of the steps.
-
-
Create a docs.gitlab.com release merge request 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.
-
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:
-
Verify that the pipeline for the stable branch has passed and created a Docker image tagged the release version. (If it fails, how do I fix it?) -
Deploy the versions:
-
Merge the docs release merge request. -
Go to the scheduled pipelines page and run the Build Docker images weekly
pipeline. -
In the scheduled pipeline you just started, cancel the pipeline, and manually run the image:docs-latest
job that builds the:latest
Docker image. -
When the job is complete, run the Build docs.gitlab.com every hour
scheduled 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
in a comment and invite them to read and participate in the retro threads.@gl-docsteam here's the docs release issue for XX.ZZ with some retro threads, per our [process](#on-the-22nd-or-the-first-business-day-after).
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.