Skip to content
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

Maui Scenario Workload Download Error #2230

Closed
LoopedBard3 opened this issue Feb 1, 2022 · 3 comments · Fixed by dotnet/runtime#64692
Closed

Maui Scenario Workload Download Error #2230

LoopedBard3 opened this issue Feb 1, 2022 · 3 comments · Fixed by dotnet/runtime#64692
Assignees
Labels
bug Something isn't working dependencies Pull requests that update a dependency file Scenario

Comments

@LoopedBard3
Copy link
Member

The workload download being completed for the Maui scenarios has been broken for some time (exact time is unknown, likely around transition from 6.0.1xx runtime to 6.0.2xx runtime usage for workload packages). Unfortunately, the error did not cause the pipelines to error out, instead the dotnet workload install just downloaded the newest compatible packages it could find. This can be seen:

Updated advertising manifest microsoft.net.sdk.ios.
Updated advertising manifest microsoft.net.workload.mono.toolchain.
Installing workload manifest microsoft.net.sdk.android version 31.0.200-preview.13.35…
Workload installation failed. Rolling back installed packs...
Installing workload manifest microsoft.net.sdk.android version 31.0.101-preview.9.16…
Installation rollback failed: Failed to install manifest microsoft.net.sdk.android version 31.0.101-preview.9.16: The transaction has aborted..
Workload update failed: Failed to install manifest microsoft.net.sdk.android version 31.0.200-preview.13.35: microsoft.net.sdk.android.manifest-6.0.100::31.0.200-preview.13.35 is not found in NuGet feeds https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json;https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json;https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json;https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet7/nuget/v3/index.json;https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet7-transport/nuget/v3/index.json;https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet6/nuget/v3/index.json;https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet6-transport/nuget/v3/index.json;https://pkgs.dev.azure.com/azure-public/vside/_packaging/vs-buildservices/nuget/v3/index.json"..

Installing pack Microsoft.Maui.Core.Ref.android version 6.0.101-preview.9.1805...
Skip NuGet package signing validation. NuGet signing validation is not available on Linux or macOS https://aka.ms/workloadskippackagevalidation .
Writing workload pack installation record for Microsoft.Maui.Core.Ref.android version 6.0.101-preview.9.1805...
Installing pack Microsoft.Maui.Core.Runtime.android version 6.0.101-preview.9.1805...

The current approach, which closely matches what is done in the Maui repo, is to just download the latest version of the dotnet sdk and then install the workloads: Most specifically seen https://github.com/dotnet/maui/blob/main/src/DotNet/DotNet.csproj#L7-L19 and https://github.com/dotnet/maui/blob/553b69bc5c5dea29f95a72ae331a6fd526df6ffb/eng/cake/dotnet.cake#L23-L45 or in the build pipeline output covering these steps.

@LoopedBard3 LoopedBard3 added bug Something isn't working dependencies Pull requests that update a dependency file Scenario labels Feb 1, 2022
@LoopedBard3 LoopedBard3 self-assigned this Feb 1, 2022
@steveisok
Copy link
Member

@jonathanpeppers do you have any info that might help? Is the suggested workaround the right way?

@jonathanpeppers
Copy link
Member

This is now using --from-rollback-file https://aka.ms/dotnet/maui/main.json

It's the same concept we've been advertising here: https://github.com/dotnet/maui/blob/main/.github/DEVELOPMENT.md#net-maui-workload

That file is updated by dotnet/maui's CI, and should be a set of workloads that work together.

I think that is the right approach. @LoopedBard3 will be be able to see the version numbers of packs when things go wrong? As long as there is a log that says what packs are getting installed, we should be good.

@LoopedBard3
Copy link
Member Author

Yes, the version numbers of the packs should be pretty easily findable when something goes wrong. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working dependencies Pull requests that update a dependency file Scenario
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants