Link through to ingested PRs from FF PRs

[premun]

Context

Devs are asking for an easy to figure out if their change (PR) made it to the VMR yet.
One cheap and efficient way would be linking to ingested PRs on the codeflow PR description (maybe in a collapsible block so that these are not obscuring the description too much).

Goal

Figure out how to walk through the currently flown commits and link them in the codeflow PR description so that the codeflow PR shows up linked on their already merged PR timeline.

Questions

❓ Most commits have the issue #XYZ in their commit title so maybe that would be enough?
❓ Do we want to consider linking commits as well? Not sure if that shows up.
❓ Do we want to do this in backflows? Would be a bit harder to do because we'd have to filter commits that changed the repo directory, but doable.

[akoeplinger]

Most commits have the issue #XYZ in their commit title so maybe that would be enough?

yeah. you'd need to rewrite the commit title to make the #XYZ point to the repo though.

Do we want to consider linking commits as well? Not sure if that shows up.

It shouldn't show up afaik.

Do we want to do this in backflows? Would be a bit harder to do because we'd have to filter commits that changed the repo directory, but doable.

you mean manual changes that originated in the VMR?

[akoeplinger]

Here's how dependabot does it btw: dotnet/runtime#119365

I think it'd work ok for repos like runtime which enforce a flat/linear commit hierarchy. I'm not sure how well it handles other repos.

[mmitche]

• Using # would work, though might generate odd results in cases of backport PRs in the original repository. You know what the original remote is when doing the FF sync, so I don't think you need to rewrite the orignal commit title.
• I would focus on linking PRs over commits. We already link commits implicitly via the diff link.
• You mean linking VMR PRs on backflow? I would keep it simple and just link them all, rather than attempting to filter by source dir.

[akoeplinger]

Ah I also just remembered that you only really need to list the PR link itself and GitHub will print a pretty title link when it's in a markdown list like this:

- https://github.com/dotnet/runtime/pull/119365
- https://github.com/dotnet/runtime/pull/119348
- https://github.com/dotnet/runtime/pull/119366

becomes

• Bump actions/github-script from 7 to 8 runtime#119365
• Bump actions/setup-dotnet from 4 to 5 runtime#119348
• Bump actions/setup-node from 4 to 5 runtime#119366

[jaredpar]

Most commits have the issue #XYZ in their commit title so maybe that would be enough?

Would strongly prefer focusing on PRs vs. commits. Not everyone or every scenario squashes. Think that PRs are the better item to focus on. Particularly because devs are usually interested in "did that PR make it to VMR" not "did that commit make it".

[tmat]

Devs are asking for an easy to figure out if their change (PR) made it to the VMR yet.

The most important information is the build number of the first build of the product (.NET SDK) that includes a given PR.

Perhaps, when an official build of .NET SDK from VMR successfully completes it could create an issue that has links in its description to all PRs included in this build that were not included in the last successful build.

Whenever .NET SDK is inserted into VS another issue can be automatically created with links of the PRs contributing to the insertion along with the build numbers of VS and .NET SDK.

[premun]

@tmat can you send me an example issue/PR with this?

[tmat]

Here: is an example: dotnet/roslyn#80074

[dkurepa]

Hi @tmat, your suggestion sounded like a different issue for this one, so I created a separate issue for it to keep track of it #5356