Open
Description
Current workload process
- Maui builds workloads in three repos, aspire one, and runtime two
- Each workload creates its own drop and inserts into Visual Studio independently (though sometimes we coordinate)
- joeloff is working on an automated pipeline for generating the drops for at least runtime if not more
- There are 19+ different drops created (more because there are component drops for each downlevel version as well):
- Workload set versions are manually updated by marcpopMSFT in the workload set repo using darc typically the day after release and pushed to internal feeds using the AzDO pipeline
Ideal process
Note: we can scope this based on where the workload owners are
- Each workload owner publishes release ready versions to the dotnet8-workloads and dotnet9-workloads channel (and feed)
- Workload set repo PRs are created based on the release channel (today they are flowing every build to the net8 channel)
- A person reviews the PR, approves, merges, and a build is triggered automatically
- A person triggers a workloads staging build when ready to insert/test
- The build uses darc information in version.details.xml to get the builds for each workload
- Downloads the workloads details from each of the upstream builds
- Creates a vsdrop for each workload
- One alternative here would be for each workload build to create its own drop and for the staging build to just grab that from the upstream build rather than needing to grab the workloads assets
- Creates a VS PR with the workloads json file updated
- We test the VS PR, signoff, and merge the workload set and all workloads together
Note, that additional work around the baseline workload set in the stand-alone sdk and how the resolver will work with a workload set installed by VS need to be covered in parallel to this.