docs.gitlab.com release 16.2 (July, 2023)
Tasks for all releases
Documentation for handling the docs release is available.
Prerequisites:
- Make sure you have all the needed tools installed on your system.
Terminology:
The following terms are used throughout this document:
-
Stable branch: This is the branch that matches the GitLab version being released. For example,
for GitLab 16.0, the stable branch is
16.0
.
On the 21st of each month
-
Cross-link to the main MR for the release post: gitlab-com/www-gitlab-com!126593 (merged) -
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?
-
Check for the stable branches that correspond with the release:
-
gitlab
: https://gitlab.com/gitlab-org/gitlab/-/branches?state=all&sort=updated_desc&search=stable-ee- -
gitlab-runner
: https://gitlab.com/gitlab-org/gitlab-runner/-/branches?state=all&sort=updated_desc&search=-stable -
omnibus-gitlab
: https://gitlab.com/gitlab-org/omnibus-gitlab/-/branches?state=all&sort=updated_desc&search=-stable -
charts/gitlab
: https://gitlab.com/gitlab-org/charts/gitlab/-/branches?state=all&sort=updated_desc&search=-stable (Version number is 9 lower thangitlab
release, so GitLab 16.X = Charts 7.X)
-
-
When all the stable branches are available, create a stable branch and Docker image for the release: -
In the root path of the gitlab-docs
repository, update your local clone:make update
-
Create the stable branch: make create-stable-branch
- A branch
X.Y
for the release is created. - A new
X.Y.Dockerfile
is created and automatically committed. - The new branch is pushed.
After the branch is created, the
image:docs-single
job runs and creates a new Docker image tagged with the name of the stable branch (for example, see the 15.6 release pipeline). - A branch
-
Share the following message in the #tw-team
channel:📣 The stable branch forgitlab-docs
was created. You can now make changes to docs navigation as usual.
-
You can continue onto the next process immediately, or wait for the release post.
On the 22nd, or the first business day after
After the 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 (filter by branch) has passed and created a Docker image tagged with the release version. (If it fails, how do I fix it?) - To filter the list of pipelines to the stable branch, select the Branch name filter then manually input the stable branch's name. For example, "Branch name = 16.0".
-
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. -
Deploy the versions:
-
Merge the docs release merge request. -
Go to the scheduled pipelines page and run the Build Docker images manually
pipeline. -
In the scheduled pipeline you just started, wait for the test:image:docs-latest
job to finish, then manually run theimage:docs-latest
job that builds the:latest
Docker image. -
When the image:docs-latest
job is complete, run theBuild 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. -
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.