Known issues infrastructure should work for official builds

[riarenas]

• [ ] This issue is blocking
• [ ] This issue is causing unreasonable pain

Currently the known issues infrastructure seems to only work on issues reported for PR builds, but knowing the impact of a given internal-only issue seems like it would be a good thing to have so we can make decisions like escalating ICMs or drive feature work towards a particular area.

[missymessa]

@riarenas, is this request the same or similar to: https://github.com/dotnet/arcade/issues/10732? If so, we're not going to get to this work for this epic. We do plan to provide documentation for how to discover this here https://github.com/dotnet/arcade/issues/10878 if that's sufficient.

[riarenas]

Nope, this is not the same. This isn't really about build analysis, but whether I can find the impact of an issue that happens in an official build instead of a PR.

I don't really need it to be displayed on any check. Just to be able to open an issue that is reported in an official build, and have the nice summary of hit count and impacted builds to determine whether we want to engage with Azdo, etc.

[missymessa]

Okay, guess we should talk about how what you're requesting is different from Andy's request, because that sounds very similar to me. (#10732 is not related to Build Analysis, either).

[riarenas]

Also note this isn't for CI builds, but rather official builds, so that we could track issues with signing, publishing, etc.

The issue you linked specifically mentions users would like to see the same summary that build analysis gives in their CI and outer loop runs. I just want the impact information we get in the issue itself

[missymessa]

I see. We'll probably have to find a new home for this issue then :(

[missymessa]

Notes for triage: This issue is somewhat similar to another that was added to this epic: https://github.com/dotnet/arcade/issues/10877. However, since this is around official builds rather than CI builds, it doesn't exactly fit with that epic. So we should figure out where a good place would be for this. (It's outside the scope of the current DevWF epic, which encompasses Pull Requests).

[riarenas]

Another way to summarize this is: Known issues should look for builds in dnceng/internal as well as dnceng/public and dnceng-public/public.

[riarenas]

I think it makes sense that it doesn't fit the pr dev wf epic, but I would be sad if it doesn't fit in the known issues epic, as currently we're only able to have known issues for the public side of things, and will still need to use runfo for anything internal.

[missymessa]

@ulisesh please follow up here.

[markwilkie]

Known issues should look for builds in dnceng/internal as well as dnceng/public and dnceng-public/public.

This is true- is that problamatic?

I think it makes sense that it doesn't fit the pr dev wf epic,

Known issues and Dev WF are the same..... (at least for this kind of conversation)

[michellemcdaniel]

This almost feels like it should just be its own epic for the non-PR side of the house

[riarenas]

I think its own epic makes sense if this isn't straightforward, but given how I'm only asking to expand the search to a new org, and we already have multi org support, it seems like something that shouldn't require its own epic.

We probably need an answer to Mark's question above on how difficult / problematic it would be to include dnceng/internal in the search.

[missymessa]

Added this to https://github.com/dotnet/arcade/issues/11065 epic

[AlitzelMendez]

this was done on this issue: https://github.com/dotnet/arcade/issues/12939

feel free to reopen if something else is needed