Evaluate Release Infrastructure for building from the VMR

[mmitche]

When building from the VMR, all repos are built from the same repository. This will have some effect on the gather, staging, and release pipelines. We need to identity and file issues for areas that will need changes.

The VMR build artifacts will match what we get from the union of all the .NET builds used to ship the release today. For example, instead of getting a series of repos that produce sets of shipping and non-shipping packages, we'll get two huge sets. It is expected that the artifact identification process will be identical (or very close) to what is in use today (https://github.com/dotnet/arcade/blob/96e79593b458ac7aeff2571604c41fe915da5bff/src/Microsoft.DotNet.Arcade.Sdk/tools/Publish.proj#L66-L181).

One way to approach this exercise might be to imagine that the input to gather-drop is a single build BAR id from the dotnet-dotnet AzDO repo. Then work downstream through darc's gather-drop and the staging pipelines to see what could be affected. File issues accordingly,

Examples include:

• gather-drop knows about the release NuGet package layout. It identifies a discreet set of repos that produce shipping Nuget packages that .NET's release processes should handle. Anything else (e.g. Roslyn packages) would get dropped and not published by .NET. This is by design since those repo owners should publish their own packages on their own schedule. If all packages start showing up from dotnet/dotnet, this package identification will no longer work.
• The staging pipeline splits outputs by repo and checks signing status based on the signing exclusions in that repo. It won't be as easy to split these artifacts by repo, so how do we check signing? We can check signing of all the binaries, but we do need some level of information about exclusions.
• Similar as above, but for localization?
• How might our publishing be affected? When we publish outputs to staging locations, will something break?

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[mmitche]

@MilenaHristova

[MilenaHristova]

So far I used the manifest.json from the 8.0 release and moved all of its assets to one build of dotnet-dotnet. I ran a test build of the staging pipeline (link) using this generated manifest to see where it will break and opened a few issues for stages that depend on the manifest format containing multiple repo builds.
What I am looking at now is

• what stages depend on the MergedManifest.xml. I have now created a manifest that merges all "merged manifests" from the 8.0 release and will try to use in it the pipeline
• creating a full picture of the interface between staging and release pipelines. (Most of it is documented in a wiki page)
• which part of this interface will be affected by the VMR