Enable the flow of NoWarns to inner build

[mthalman]

There can often be cases where Roslyn analyzer warnings (which typically get treated as errors) show up in the stage 2 build of source build. This is because the stage 2 build makes use of the most recent SDK to build the repos and those repos can have source which isn't compliant with new analyzers included in that SDK.

To unblock the build, it was often useful to simply add a NoWarn entry for the specific analyzer type. (It's up to the underlying repo to fix the issue and these analyzer issues shouldn't block a build of the VMR.) But the ability to set a NoWarn entry for a repo was removed as part of the changes in dotnet/installer#17712.

In the absence of ignoring the error, the only resolution is to apply the fix. Some fixes for analyzer issues can be quite extensive in some cases; others can be simple. The most expedient way to unblock the VMR build is to create a patch. But depending on the changes involved, this may not be a great solution. As we got closer to a release cutoff date, there's a need to have a quick turnaround to resolve these issues. Therefore, we should reconsider having a mechanism that allows us to flow NoWarn entries to the inner build of repos.

[ViktorHofer]

With the unified build, won't this issue go away as we can make the fix or set the NoWarn directly in that repo folder and that change would then automatically flow back into the repo?

[mthalman]

With the unified build, won't this issue go away as we can make the fix or set the NoWarn directly in that repo folder and that change would then automatically flow back into the repo?

Yes, that's exactly why I originally didn't bother writing this issue. But after a conversation with @MichaelSimons we determined it would be worthwhile to have something at least written up. There may be a need to modify the plan that would enable backflow support based on schedule/resource constraints.

[MichaelSimons]

[Triage] If the Unified Build is not shipped in 9.0, we may consider adding this infra back as it is a convenient way to address new compiler warnings from building with the latest SDK until the product team updates the code. The alternative is for the SB team to add a patch which is more difficult to maintain.