Skip to content

Create and Publish VerticalManifests during unified builds #4198

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tracked by #4158
dkurepa opened this issue Mar 11, 2024 · 7 comments
Closed
Tracked by #4158

Create and Publish VerticalManifests during unified builds #4198

dkurepa opened this issue Mar 11, 2024 · 7 comments
Assignees

Comments

@dkurepa
Copy link
Member

dkurepa commented Mar 11, 2024

During unified builds, we run many legs on different OSes. Each of these legs builds multiple repos, and every repo build produces an Asset Manifest, that's later used in the publishing. Based on #4158, we want to use these Asset Manifests to create a Vertical Manifest that will contain information about all assets built in a unified build leg.
We will exclude all of the information about signing, we don't need it

@ghost
Copy link

ghost commented Mar 11, 2024

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.

@dkurepa
Copy link
Member Author

dkurepa commented Mar 12, 2024

I discussed the implementation details with @ViktorHofer. We'll be adding Publishing.props to the dotnet/dotnet repo that will call a task that will create the VerticalManifest, and initialize a list of files that we want to publish to the remote storage for a given leg

@ViktorHofer
Copy link
Member

What I still want to double check with @mmitche is if the task should live in Arcade of the VMR orchestrator. When we invoke the publish action on the VMR we will call into the VMR and will need to make it not again produce a repo manifest. Alternatively if we implement this in Arcade we could add a new mode to the manifest generation that just accepts the other manifest files as an input. I'm not sure which approach is better.

@mmitche
Copy link
Member

mmitche commented Mar 12, 2024

When we invoke the publish action on the VMR we will call into the VMR and will need to make it not again produce a repo manifest

What do you mean by it producing a repo manifest again?

@ViktorHofer
Copy link
Member

@dkurepa, @mmitche and I discussed this offline. Just to add to what @dkurepa mentioned above:

We'll be adding Publishing.props to the dotnet/dotnet repo that will call a task that will create the VerticalManifest, and initialize a list of files that we want to publish to the remote storage for a given leg

@dkurepa given that we won't use Arcade's publishing infrastructure and our current build entry points, it would be easier if we just invoke the merge manifests build task in a target in build.proj that runs AfterTargets="Build" in the VMR orchestrator and write that new file directly into the artifacts folder.

@dkurepa
Copy link
Member Author

dkurepa commented Mar 15, 2024

The PR for this change is in dotnet/installer#19062. We'll have to wait for dotnet/installer#18917 to get merged before merging this tho

@dkurepa
Copy link
Member Author

dkurepa commented Mar 27, 2024

The pr was merged. Every VMR build leg is now producing it's own artifact that has the packages, and vertical manifests. There's a small bug with the VmrBuildNumber attribute, we opened up #4263 for it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

No branches or pull requests

4 participants