Build the SourceBuilt tarball in the publish job and include the merged vertical manifest in it.

[jkoritzinsky]

This (in combination with #19389) will allow us to rely exclusively on asset manifests for Versions.props inputs instead of grepping NuGet packages.

[ViktorHofer]

I don't understand why we need to move these targets from installer.proj into publish.proj. Can you please provide some more information on that?

[jkoritzinsky]

We produce the merged manifest in publish.proj, which in my understanding is after installer.proj, so we need to move the production of the tarball to publish.proj so we have the merged manifest available.

[ViktorHofer]

so we need to move the production of the tarball to publish.proj so we have the merged manifest available.

Still confused. How is the generation of the Private.SourceBuilt.Artifacts archive connected to the creation of the merged manifest?

[jkoritzinsky]

This PR is putting the merged manifest in the Private.SourceBuilt.Artifacts archive (so in the future I can consume that instead of globbing the packages extracted from the tarball).

[ViktorHofer]

I see. I think we should put the creation of the Private.SourceBuilt.Artifacts archive into a separate .proj (in the eng folder next to the other ones) and make it depend on the publish.proj via a P2P. We should also rename publish.proj to something like merge-manifests.proj. We can then add that new proj to build.proj and run it after the repo builds.

[jkoritzinsky]

I've moved most of the logic into the already-existing finish-source-only.proj project as that one already produces other tarballs for source-build and is SB-only already. I didn't change the name for publish.proj to limit the changes.

[ViktorHofer]

We discussed in a previous meeting that we want to use the "Request changes" action more often for VMR changes. Here it's just my comment around defining a normal P2P without an extra entry point target that needs to be resolved, otherwise looks great.

And I agree that using the finish-source-only.proj file makes more sense.

[MichaelSimons]

Do you see the manifest replacing the PackageVersions.props entirely at some point? Or another way, do you see the properties removed from the PackageVersions.props that come from the merge manifest?

[jkoritzinsky]

I could definitely see us only using the manifest. We'd have to make some changes to the bootstrapping project to handle the ExtraPackageVersionPropsPackageInfo items below itself to avoid breaks.

I have another branch that moves the WritePackageVersionProps below to be based off the vertical manifest and changes the consumption of the previously-source-built assets (when generating Versions.props) to use the asset manifest (which obviously needs to wait for the next rebaselining).