Proposal: Update Release Manager dashboard to visualize pending merge requests to be backported
Context
TL;DR: Release managers need a way to visualize what are the pending merge requests ready to be released.
While working on the maintenance policy extension, the patch release process has been adjusted to meet the following criteria:
- Engineers are enabled to merge into the current stable branch.
- Release managers reference the patch release pressure to get an understanding of the number of backports ready to be merged.
While the new patch release process is simpler, there is still a gap: There is no straightforward way to know which merge requests waiting to be released. This knowledge is required when:
- Analyzing the S1/S2 patch release pressure - This indicates there are high-priority backports waiting to be released but there is no easy way to tell which are those merge requests, their severity, nor which project they belong to.
- Building the blog post of a patch release - The blog post is automatically generated when the
/chatops run release prepare
command is run, the problem is if a backport is merged after the blog post was generated, there is no easy way for release managers to be aware of this situation. - Sending the pending merge requests to AppSec during a security release - When a security release is being prepared AppSec needs to know what are the pending bug fixes (non-security) one so they can be mentioned in the blog post.
Proposal: Have a blog post that lists pending merge requests to be released.
A pending blog post could be built and refreshed every time a backport is merged, serving as a reference of backports that are ready to be released.
How would this work?
- GitLab engineers merge a backport into a stable branch
- A stable branch pipeline includes a job that triggers the functionality
- If the blog post doesn't exist, it is created at that moment
- If the blog post exists, it is refreshed with the pending content.
- On patch releases, release managers will adjust the blog post (title, date, etc)
- AppSec will reference the blog post when fetching bug fixes for the security release blog post
- The blog post could be linked from the release manager dashboard (it will need to have a dedicated label for it)
- The blog post format could be modified to also indicate the severities (we might need to consult with product about this)
Advantages
- Anyone can contribute to the blog post, this solves #2927
- It keeps the automation of the blog post
- Serves as a reference point for backports that are ready to be merged.
Implementation details
- A new job in the stable branch pipeline needs to be added to update the blog post
- Blog post generation needs to be disassociated from patch releases
- The
PatchRelease::Coordinator
logic could be re-used to fetch pending backports.
Previous options
Option A: Visualize the information on Slack
Currently being developed on gitlab-org/release-tools!2300 (merged)
Expand the release:pending_merge_requests
command to indicate the severity of the merge requests, this would help release managers react faster if for example there are two S1 backports waiting to be backported.
Pros
- Relatively easy to implement
Cons
- Slack output might not be the best format, if the list of pending merge requests is large the Slack output gets unmanageable.
- Slack is also ephemeral, it lasts 90 days and then messages are removed.
- If we ever need to add more information, the Slack message can get out of hand.
Option B: Visualize the information on release task issues.
Similar to release:pending_merge_requests
, this command could be updated to post a note on the patch release or the security release issue to indicate what are the pending merge requests ready to be backported
Pros
- Relatively easy to implement
- Information can be shared between multiple Stakeholders
- Keeps the release issues as a single source of truth.