You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Current workload process
Ideal process
Note: we can scope this based on where the workload owners are
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.
The text was updated successfully, but these errors were encountered: