docs.gitlab.com release 15.4 (September, 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!110751 (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. You can expect the image:docs-single job to 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.
  4. 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:

  1. 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?)

  2. Deploy the versions:

    1. Go to the scheduled pipelines page and run the Build Docker images weekly pipeline.
    2. In the scheduled pipeline you just started, cancel the pipeline, and manually run the image:docs-latest job that builds the :latest Docker image.
    3. When the job is complete, merge the docs release merge request.

  3. 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.

  4. Check all published versions of the docs to ensure they are visible and that their version menus have the latest versions.

  5. 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?

  6. 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:

  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.

Helpful links

Edited by Kati Paizee