docs.gitlab.com release 16.11 (April, 2024)
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 Monday the week of the release
-
Cross-link to the main MR for the release post: gitlab-com/www-gitlab-com!133714 (merged) (Need help finding the MR?) -
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?
-
Add the version to be removed from the dropdown to the docs archives. This would be the oldest version from the last_minor
hash inversions.json
.-
Edit
archives.Dockerfile
and add a new line at the end of the file with the archived version. It should read like:COPY --from=registry.gitlab.com/gitlab-org/gitlab-docs/archives:<version> ${TARGET} ${TARGET}
-
Create the merge request in
gitlab-org/gitlab-docs-archives
and merge it.
-
-
Create a stable branch and Docker image for the release. 8aa8d3e4
Create a stable branch and Docker image for the release
Note: an issue exists to create the stable branch automatically.
-
In the root path of the gitlab-docs
repository:-
Update your local clone:
make update
-
Install all project dependencies:
make setup
-
-
To practice running the task and check the process, run the Rake task in dry run mode: DRY_RUN=true make create-stable-branch
-
Create the stable branch: https://gitlab.com/gitlab-org/gitlab-docs/-/pipelines?page=1&scope=all&ref=16.11 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.
- A branch
On the Thursday of the release, or the day after
After the release post is live, or the day after:
-
Check that the stable branches that correspond with the release are present:
-
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)
If not, you cannot proceed to the next step, so you'll have to wait.
-
-
Run a new pipeline targeting the docs stable branch after all upstream stable branches have been created. When the pipeline runs, the image:docs-single
job builds a new Docker image tagged with the name of the stable branch containing all the versioned documentation (for example, see the 15.6 release pipeline).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 versions of the docs in the version dropdown to ensure they are visible and that their version menus have the expected versions. - Versions hosted on
docs.gitlab.com
should show the same version options as the pre-release site. - Versions hosted on
archives.docs.gitlab.com
should only show their own version and a link back to the archives page.- This applies to v15.6 and newer; older versions may have broken links in the dropdown. This will eventually be resolved as the older versions are phased out.
- Versions hosted on
-
Share the following message in the #tw-team
channel::mega: The docs <version> release is complete. If you have any feedback about this release, add it to the retro thread in <this issue>.
After the docs release is successful:
-
Create a release issue for the next release, and assign it to the TW who completed the release post structural check for the previous milestone. #1779 (closed) -
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.