Enhance changelog format

What does this MR do?

Enhance changelog format

Changelog entries now include a link to the originating merge request instead of the shortened hash of the commit that added the changeset. The author is also mentioned.

The original motivations for this are:

• Existing changelog entries in Renovate MRs are kind of broken, since the bare, short sha references don't point to the right place. See gitlab-org/gitlab!228467 (merged) for an example: expand the release notes, and see the broken d3b19ac link. This makes it annoying to:
  • Find the original author.
  • Investigate the original change, e.g., to see if an integration MR was already opened.
• There's confusion around how to merge @gitlab/ui updates into the monolith. This mostly revolves around the apparent race between integration merge requests created by the ui:create_integration_merge_request manual job and Renovate MRs.

So, this MR of course solves the first problem, by replacing the bare, short sha with full merge request links. Now, while the bad link is probably a bug in Renovate, and we could look into fixing that upstream, I think having a link to the merge request is more useful anyway. It's where all the discussion around the change happened, which is more useful context than the commit alone.

I'm also planning on making other changes to help with the second:

• Make publish_npm_packages run in a scheduled pipeline only.
  • This would rate-limit how frequently @gitlab/* packages get released. At the moment, packages can get released repeatedly in quick succession, which can create noisy/multiple Renovate MRs.
• Set separateMajorMinor: false in the Renovate config for @gitlab/ui updates to the monolith.
  • Currently, it frequently happens that there are two open Renovate MRs: one with a minor bump, one with the later major bump. It also often happens that the minor bump requires updates to be mergeable. But, both are worked on simultaneously, and so work is duplicated unnecessarily. Whichever one merges first causes merge conflicts in the other, and wasted time.
• Set the reviewers of @gitlab/ui updates to the monolith to the Design System team, such that their only role is to reassign the MR to the author(s) of the updates according to the changelog.
  • This is where this MR is useful: that information will be present in the MR description, and is easy to read off. The reason for this is that the original author probably has an integration MR open with fixes for pipelines prepared. They should therefore be responsible for getting the dependency bump merged in.
  • Ideally this would be automated, but Renovate doesn't seem to offer a way to determine reviewers programmatically on arbitrary information. Perhaps there's another way to automate this, but for now, this is the boring solution. Better ideas welcome!

Part of #2884 (closed).

Screenshots or screen recordings

Example output from the dry run:

Integrations

• GitLab: mr_url
• CustomersDot: mr_url
• Duo UI: mr_url
• Status Page: mr_url
• Docs: mr_url
• Switchboard: mr_url

Does this MR meet the acceptance criteria?

This checklist encourages the authors, reviewers, and maintainers of merge requests (MRs) to confirm changes were analyzed for conformity with the project's guidelines, security and accessibility.

Toggle the acceptance checklist

Conformity

• The “What does this MR do?” section in the MR description is filled out, explaining the reasons for and scope of the proposed changes, per “Say why not just what”.
  • For example, if the MR is focused on usage guidelines, addressing accessibility challenges could be added in a separate MR.
• Relevant label(s) are applied to the MR.
• The MR is added to a milestone.
• Added the ~"component:*" label(s) if applicable.
• A changeset is added when this MR will do a patch, minor, or major update. More information can be found in doc/publishing-packages.md.

Components

• GitLab UI's contributing guidelines.
• If the MR changes a component's API, integration MR(s) have been opened (see integrations above).

Documentation

• If creating a new component page from scratch, it follows the page template structure.
• Content follows the GitLab Documentation Style Guide when appropriate.
• Related pages are cross-linked, where helpful. Component pages have related components and patterns defined in their Markdown front matter.
• If embedding a Figma file, it follows the Figma embed guide.
• Review requested from any GitLab designer or directly from a maintainer or trainee maintainer.
• Maintainer review follows the Pajamas UX maintainer review checklist.

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• Security reports checked/validated by a reviewer from the AppSec team

Accessibility

If this MR adds or modifies a component, take a few moments to review the following:

• All actions and functionality can be done with a keyboard.
• Links, buttons, and controls have a visible focus state.
• All content is presented in text or with a text equivalent. For example, alt text for SVG, or aria-label for icons that have meaning or perform actions.
• Changes in a component’s state are announced by a screen reader. For example, changing aria-expanded="false" to aria-expanded="true" when an accordion is expanded.
• Color combinations have sufficient contrast.