docs.gitlab.com release 15.3 (August, 2022)

Tasks for all releases

Documentation for handling the docs release is available.

Between the 17th and 20th of each month

  1. Cross-link to the main MR for the release post: gitlab-com/www-gitlab-com!109032 (merged)
  2. Monitor the #releases Slack channel. When the announcement This is the candidate commit to be released on the 22nd is made, it's time to begin.
  3. 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?)
  4. 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.

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:

  1. Merge the release merge requests and run the necessary Docker image builds.
    • 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.
  2. 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.
  3. Check all published versions of the docs to ensure they are visible and that their version menus have the latest versions.
  4. 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?
  5. Mention @gl-docsteam and invite them to read and participate in the retro threads.

After the 22nd of each month:

  1. Create a release issue for the next TW and assign it to them.
  2. Major releases only. Update OutdatedVersions.yml with the newly-outdated version.
  3. 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. !3056 (merged)

Helpful links

Edited by Achilleas Pipinellis