Skip to content

Update a few documentation_link fields in release posts

Why is this change being made?

I noticed a few outdated (due to renamings in gitlab-org/gitlab) documentation_links/anchors, using:

yq eval '.features.[].[].documentation_link' data/release_posts/*_*/*.yml | sort | uniq | rg 'docs.gitlab.com.+#'

Is it useful to update these few?

Generally, though: Should we consider to fill documentation_link fields the gitlab-org/gitlab/blob/…X.y.0…/doc…md#… with URLs specific to each minor release tag? That way, our release blog posts would always send customer to known, stably anchored docs section. 🤔

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

  • Provided a concise title for this Merge Request (MR)
  • Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
    • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
  • Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
    • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
    • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
    • The when to get approval handbook section explains the workflow in more detail
  • For transparency, share this MR with the audience that will be impacted.
    • Team: For changes that affect your direct team, share in your group Slack channel
    • Department: If the update affects your department, share the MR in your department Slack channel
    • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR

Commits


Edited by Katrin Leinweber

Merge request reports