ApiCatalog build infrastructure should be updated

[safern]

The ApiCatalog build should just run after the official build and use its artfacts to restore. Also, it should be shared to generate the docs layout that we use for the docs team. I already have some targets to generate the docs layout that I should tweak for this to work for both scenarios.

safern/corefx@099258b

cc: @ahsonkhan @ericstj @carlossanlop

[safern]

cc: @danmosemsft

[ericstj]

Quick thoughts on how this can work:

1. See how we construct package versions / flow package versions to the package testing leg.
2. Make a project that consumes all the relevant packages and not the raw binaries. Consider even generating such a project and saving it as an artifact.
3. Restore and publish that project to the required directories. Use the PackageId metadata as a means for partitioning inbox vs OOB.

[wtgodbe]

Here is the plan @safern and I came up with:

• Add a step concurrent to Publish Packages in the official builds that restores the packages we just built
• Use a project similar to https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.Windows.Compatibility/tests/Microsoft.Windows.Compatibility.Validation.csproj with the just-built Compat package to restore & publish ref assemblies/.xml files
• Use something like https://github.com/dotnet/corefx/blob/37a56121a88d8e67da75e2e5201f2c1c87c7b551/pkg/test/testPackages.proj#L80 to generate versions
• Replace wildcard package versions (ASPNet.Core, etc) with ToolsetDependencies in versions.details.xml, updated by DARC

[ViktorHofer]

@carlossanlop should this issue be closed now?

[ViktorHofer]

The docs team needs the following assets from repositories:

• Reference assemblies
• compiler generated XML files (for triple-slash source of truth projects)

Instead of having an orchestration point (currently apicatalog-infra repo) that bundles all the assets together from different repositories and which is a completely manually process today, we could design a push model. Any repository that needs/wants to participate in the docs team process, would generate their own transport package.

Example name pattern: Microsoft.Internal.[SourceRepo].[TargetRepo].Transport.nupkg

• dotnet/runtime -> Microsoft.Internal.Runtime.DotNetApiDocs.Transport.nupkg Create docs transport package and turn on extensions source of truth #89312
• dotnet/extensions -> Microsoft.Internal.Extensions.DotNetApiDocs.Transport.nupkg
• dotnet/wcf
• dotnet/aspnetcore -> Create transport package for API docs aspnetcore#49969
• dotnet/winforms -> The Microsoft.Private.WinForms package already contains the necessary assets.