Was the Release published to customers or an internal version
Type of release - for example major, minor, patch
The latest build identifiers -id, has value, number, deployed by etc.
For this issue, we want to enable visibility into merge requests and issues by allow users to click into the open/closed issues and MRs for a release:
Use Case 2 a user during planning will want to see how many issues within a release are planned
Show # issues, # of issues closed, and % as completion metric on releases page, for each associated milestone next to where we show the link to the milestone.
As a user, I want to see the number of relevant issues and their statuses in a release that is associated to milestones, so that I can quickly see how the Release is going.
Acceptance criteria
Users should be able to click and see the listed issues and MRs
Intended users
Anyone tracking upcoming releases
Product manager
Product Designer
Release Manager
Permissions and Security
This should follow all practices and tests for #31289 (closed)
Documentation
We will need to add for public projects only public issues are shown
Availability & Testing
This should follow all practices and tests for #31289 (closed)
What does success look like, and how can we measure that?
Users should be looking at open and closed issues related to a release
@jmeshell Thanks for opening this issue! Would it be possible to trim this issue's description down to only include the work that we want to accomplish? (I.e. just activating the links?) Right now this looks like a near duplicate of #31289 (closed), and it contains conflicting UX designs.
Ideally we would have two new, small, issues:
Adding the merge request stats to the Release block header section
Activating all links to the issue/MR search pages.
(I'm happy to create these issues if you'd like.)
Everything else described in this issue has already been implemented as part of #31289 (closed).
@jmeshell I see this issue is fairly high on the priority list of our build board, but it might make sense to wait until we've converted the Releases page to use our GraphQL endpoint being implemented in #208702 (closed).
This change will involve adding some new properties to our REST API, which isn't a big deal, but once we convert to using GraphQL, we'll need to repeat these updates to our GraphQL endpoint.
So waiting until the GraphQL work is live will push this issue out several milestones but may save us time in the long run.
I think that makes sense and am happy to prioritize all the GraphQL work as necessary- can you provide those issue links so I can block this issue with those @nfriend?
@jreporter We can actually deliver this one independently of the backend work necessary for #205349 (closed), so I think it's fine to keep in %13.6. We just won't be able to view half of the links (the MR links) until #205349 (closed) is delivered in %13.7.
@jreporter We added issuesUrl and mergeRequestsUrl to the API response to support this feature when we first began this work way back when. But when picking this back up, I realized we actually need more specific urls - one for open issues, one for closed issues, etc. So I added all the links I needed in !46161 (merged) and then deprecated issuesUrl and mergeRequestsUrl.
But then I realized these fields weren't even officially released since we never enabled the release_mr_issue_urls feature flag. So we are actually free to remove them immediately rather than going through the official deprecation/removal process.
Does that make sense? It's a bit strange/unusual 😅
!46910 (merged): Waiting for ☝ to be merged before submitting for maintainer review
I also opened #276485 (closed) to discuss how we should handle the new links added as part of this feature with regards to REST vs GraphQL. However, we don't need to make a decision in order to release this feature.