17.11 Amazon Q backport

Why is this backport needed (background and context)

Here is the discussion that led to this decision: https://gitlab.slack.com/archives/C07J0268YAX/p1744041272113889

  • Merge request to backport:

Get the approval of TW Leadership

The person requesting the backport does this step.

If the backport is for a version older than the latest stable branch, ask Technical Writing Leadership for approval:

  • Mention TW Leadership in a comment in this issue and wait for their approval:

    @gitlab-org/tw-leadership could I get your approval for this documentation backport?

Create the merge request to backport the change

The person requesting the backport does this step. Requires at least the Developer role on the project that needs the backport.

To backport a change, you will merge your changes into the stable branch of the version where you want the change to occur.

  1. Open a merge request with the backport. The MR should target the stable release branch, for example: 16-11-stable-ee or 17-0-stable-ee. Link the MR to this issue.
  2. If the backport targets the current stable branch, assign to a Technical Writer for review and merge. Usually, the Technical Writer of the relevant group.
  3. If the backport targets any branch other than the latest stable branch, assign the MR to a Technical Writer for review. After the TW approves, ask a release manager to review and merge the change. Mention this issue to them and give them all the context they need.

For the change to appear in docs.gitlab.com, merging to the stable branch is all you need.

For the change to appear under /help, the change needs to be part of a GitLab release. The next time a release manager creates a release, they will include the change in the release.

Deploy the backport change

A member of the Technical Writing team does this step. Usually, the same Technical Writer who created the merge request.

After the change is backported to a stable branch, the Docker image that holds that version's docs needs to be updated:

  • GitLab 17.9 and later:

    • Run a new pipeline in docs-gitlab-com. Choose the branch name that matches the stable version, for example 15.11 or 16.0.

  • GitLab 17.8 and earlier:

    • Run a new pipeline in gitlab-docs. Choose the branch name that matches the stable version, for example 15.11 or 16.0.

If the backport change was also made to a version other than the last three stable branches, you need to update the docs archives site:

  1. Make sure the Docker images from the previous instructions are built.
  2. Run a new pipeline in gitlab-docs-archives. Choose the branch name that matches the stable version, for example 15.11 or 16.0.
  3. After the pipeline finishes, go to https://archives.docs.gitlab.com and verify that the changes are available for the respective version.
Edited by Phillip Wells