Open AArnott opened 2 weeks ago
Triage: @AArnott does that feed exist and does it work with dotnet restore but not with workloads? Can you try adding --ignore-failed-sources? Something is not configured right with that feed and my guess is that the error case is not failing fast?
@marcpopMSFT Yes, the feed exists, and the dotnet restore
step worked successfully before dotnet workload restore
runs.
Can you try adding --ignore-failed-sources?
My nuget.config only has one source specified, with <clear/>
above that to prevent any ambient source from being added. I also set NUGET_PACKAGES
to the agent temp dir so that it's fully restore from scratch on every run of the pipeline, so I'm certain that restore works (i.e. actually downloads packages), but workload restore fails.
@nkolev92 @aortiz-msft are there logs we can collect to see the time spent in nuget for this? Have you heard of any discrepancy between nuget.org and AzDO?
Since we're talking about dotnet workload restore, I'd need to get some hints to that code so we can figure out which logs might be available. All NuGet remote calls end up calling: HttpRetryHandler which will tell you long it takes.
Normally that would be on informational verbosity, assuming the logger is passed down.
Have you heard of any discrepancy between nuget.org and AzDO?
I'd generally expect nuget.org to be faster than AzDO. Auth is one starting point. nuget.org is optimized for parallel downloads, with static blobs and CDNs, while AzDO does more compute, so it's not unusual for nuget.org to be noticeably faster than AzDO.
I don't know if it fully explains the 25s to 4 mins jump, as that'd be driven by the number of calls made, packages download and their size.
The logs posted here being full of lines saying the service index wasn't loaded are probably what I'd look into first, why there's so many failures fetching the service index resource.
Another thing I'd look into is whether the SourceRepository object is shared across all of these workload calls.
Normally that would be on informational verbosity, assuming the logger is passed down.
Probably not. Most msbuild args aren't copied to the inner invocation of msbuild, sadly.
Describe the bug
Frequent pipeline failures due to nuget.org not responding to package restore requests drives me to consider using a private Azure Artifacts feed instead of nuget.org in nuget.config.
But this change has an unexpected side-effect: the time to run
dotnet workload restore
jumps extremely:The macOS agent is the only one to display the following errors, which it does only after the change:
Eventually the work completes (successfully I guess, because the rest of the build succeeds.)
This is repeatable. And the macOS agent has the authentication necessary to pull from the private feed.
Further technical details