Show/directly link Related Merge Requests which inline in issues in the issue board.

When we are nearing the end of the release cycle, rather the MR's than the issues become important. As we use the issue board to see where we're standing during meetings.

The milestones board/lists currently can include merge requests...

This is just to spark idea's into this direction

Proposal

It would be nice to have a way to directly go to the related Merge Requests from the issue board itself.

Perhaps with a reference from the issue, or with a MR attached to an issue card

I had an idea like rip off paper:

cc: @markpundsack @victorwu @awhildy

added ~874211 label

Thanks @dimitrieh.

We've had repeated requests for deeper integration of merge requests into issue boards. Everything from making an "issue" board for merge requests, combining issues and merge requests into a common board, and something more considered from Dimitrie here. I'm really uncomfortable making merge requests first class citizens at this point in the issue board. But something like this makes more sense and maybe be in a subsequent round of iterations of issue boards soon. (But likely not in the next one.)

We currently lump all "related" merge requests associated with an issue all together. I'm not sure if technically it would be straightforward to only surface the truly "related" merge requests in a code sense. e.g. merge requests that actually close the issue. Right now, an issue is often polluted with many related merge requests because someone mentioned it in the comments. If we can solve those technical and design concerns, I can see something similar to what Dimitrie designed here to be very powerful.

I'm just commenting here because I think the design is extremely interesting. But I don't see it shipping in the immediate future just yet.

@cperessini

changed milestone to %Backlog in gitlab-foss

We currently lump all "related" merge requests associated with an issue all together. I'm not sure if technically it would be straightforward to only surface the truly "related" merge requests in a code sense. e.g. merge requests that actually close the issue. Right now, an issue is often polluted with many related merge requests because someone mentioned it in the comments.

@victorwu this is one of my main concerns indeed ;)

I'm just commenting here because I think the design is extremely interesting. But I don't see it shipping in the immediate future just yet.

My main purpose here is to throw the idea out there with a small visual ;)

However if I had to instill this idea to its bare minimum:

A "Merge Request icon + count" which yields a dropdown on the issue card which lists all related MR's in order to be able to directly link to them (open them in a new tab)

potentially like the pipeline dropdown with a status of open/closed/merged:

Will result in something like:

@dimitrieh : That's pretty slick!

I agree that this is interesting! I lean more towards the bare minimum approach with the dropdown as there is already a lot going on with the issue board and what it is trying to show. If there is just 1 related merge request, it could just be the icon in the button, hover would show you the name of the merge request, and click would navigate. With more than 1, I like the dropdown. Just a thought. Thanks!

Technical note: Getting merge requests for an issue is currently very expensive, so we cannot do that for each rendered issue in the issue board using the current method. However, the MergeRequest#merge_requests_closing_issues relation and MergeRequestsClosingIssues model may come in handy.

mentioned in issue gitlab-foss#27533 (closed)

mentioned in issue gitlab-foss#19786 (closed)

mentioned in issue gitlab-foss#27053 (closed)

removed milestone

mentioned in issue gitlab-foss#23856 (closed)

mentioned in issue gitlab-foss#22346 (closed)

from: https://gitlab.com/gitlab-org/gitlab-ce/issues/22346#note_15911453

This is how it's done on codetree

This design had a similar idea, but in a different context.

I do think that https://gitlab.com/gitlab-org/gitlab-ce/issues/25669#note_20017695 will perhaps be the simplest first step to implement.

@victorwu @markpundsack @JobV just closed https://gitlab.com/gitlab-org/gitlab-ce/issues/23856 and https://gitlab.com/gitlab-org/gitlab-ce/issues/22346 in favor of this issue. Will this get any milestone eta?

changed milestone to %Next 3-6 months in gitlab-foss

@dimitrieh My initial reaction is that I greatly prefer the smaller indicator, like in https://gitlab.com/gitlab-org/gitlab-ce/issues/25669#note_20017695 since the issue should be the main thing and I don't want MRs taking up too much space. This doesn't even add any vertical space, which is great.

But then looking at the codetree, it looks like they're treating the issue almost in the same way we talk about epic issues, where the details of the work is in the MRs. If that's your flow, I could see wanting all the MRs listed with details. Although even if we do it like the former example, the details are only a click away in the dropdown so maybe that's good enough for both cases.

Lastly, looking at the proposal in the description, I could see it being progressive where if there's a single MR, it's shown like the left-most image (minus the Show more link), then if there's two, show the right image, at some point condense them down to the 3rd image.

But reiterating my first point, in our flow, where MRs are usually 1:1 with issues, the title of the MR just isn't relevant since it's redundant with the issue title, and the only reason I want the MR info there is to be aware of which issues have WIP, and a quick link to get to them.

FWIW, the Production mockup shows more MR details because it's got a different purpose and the MR content can't be deduced by anything else on the page.

So, I'm in favor of , and when you click on the MR count, it shows a dropdown with similar information to (although I don't know what the checkmarks mean in that image).

moved from gitlab-foss#25669 (moved)