Silent workload updates break builds #40222
Comments
|
Update: After submitting this, the dependent nuget package showed up (~3-4 hours later). The issue still remains, we need a way to pin a version of the workload (without using the undocumented and hard to find rollback file). Because pinning a dotnet version doesn't stop the problem. |
|
Same type of issue, but different package: dotnet/maui#19934 |
|
@svaldetero please try again. It seems there was a delay in publishing of some packages for this update, which should now be available. |
|
Related: #23820 |
|
@Redth Yes it works now after I removed the rollback option. As a developer, how do I prevent this in the future? How can I pin a workload version without having to find a hidden rollback file? In that issue you linked, it doesn't happen every time, but it happens frequently enough. Today it just happened to be ~3 hours before all the nugets were available. That suddenly blocks and backlogs ALL of my builds for close to half the day. Realistically, I can't just wait for the delay to catch up because I don't know how long it will be. |
|
I experienced the same with "dotnet workload install maui" in my GitHub workflow today. I changed it to "dotnet workload install maui-mobile" and it works for me for now. |
|
For us, the way we managed to "pin" the MAUI version for Android CI builds is by building in docker, which we need to do anyway for CI. For an example see our repository. Note: We do not use the docker for builds on the developer's own machine, but updating MAUI there takes only a minute when it breaks. |
|
Problem: Solution:
Suggestion: |
dotnet-issue-labeler
bot
added
Area-Workloads
untriaged
nagilson
added
needs team triage
|
Without functionality in nuget to batch these, the best we have is pushing all of the packs first and then the manifest. Looking forward, we'll have workload versions coming soon that will make this easier as we can ensure all of the packs and manifests are published and then publish a single workload set version package. |
Description
Another update Tuesday and another broken Azure Pipelines CI build. One build works and then an hour late the build breaks.
I have a step to use a dotnet version 8.0.x. It downloads 8.0.203. Specifically: https://download.visualstudio.microsoft.com/download/pr/87f31249-1415-4edb-87d5-7f16e63414e9/a1ad58c05a131c618ad458a1564784e4/dotnet-sdk-8.0.203-osx-x64.tar.gz.
Next step is to:
dotnet workload install maui-ios maui-android --source https://api.nuget.org/v3/index.json.The first time it ran, it installed successfully:
The second time it ran (an hour later), it failed:
Looking at the nugets:
https://www.nuget.org/packages/Microsoft.NET.Workload.Mono.ToolChain.Current.Manifest-8.0.100/8.0.4 was published between the builds.
HOWEVER, the nuget package that it claims is required:
https://www.nuget.org/packages/Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100/8.0.4
DOES NOT EXIST.
I understand these may be separate teams, however these nugets should have been deployed at the same time.
Steps to Reproduce
No response
Link to public reproduction project repository
No response
Version with bug
8.0.7 SR2
Is this a regression from previous behavior?
No, this is something new
Last version that worked well
8.0.7 SR2
Affected platforms
iOS, Android
Affected platform versions
No response
Did you find any workaround?
I changed my workload restore to include :
--from-rollback-file https://maui.blob.core.windows.net/metadata/rollbacks/8.0.7.jsonRelevant log output
No response
The text was updated successfully, but these errors were encountered: