First time we’ve run into this issue, we last deployed on Friday and now dotnet restores are timing out when I run fly deploy. If I add the --local-only tag, I can deploy that way just fine.
error NU1301: The HTTP request to ‘GET https://api.nuget.org/v3/index.json’ has timed out after 100000ms.
error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json.
Hm… Just to clarify, dotnet restore is an installation command, and nuget is the package repository that it’s attempting to talk to?
(Relatively few people in the community forum here are conversant with the .NET ecosystem, so any additional hints that you can give…)
If builds work locally then you could continue to do this. It’s a bit slower, since the Docker image has to travel over the wire to the destination server, but otherwise it is a perfectly good way to deploy.
That’s correct, sorry for the lack of detail! The main issue is from that request that dotnet restore does to api.nuget.org timing out on the fly.io build runner.
Thanks for the confirmation. It would be good if the fly.io team saw this and could double check on the machine running the build, but in terms of performance I haven’t noticed any problems with doing the local only flag.
If you’ve been using a Depot builder, you can reset your instance in your settings: https://fly.io/dashboard/{username}/settings. However, you might also try turning off Depot and using the old remote builder. I wonder if something has got some networking issues…
It would be wise to post the app ID, in that case, since, as far as I can tell, they can’t really infer your organization, etc., from seeing just your name in the forum.
(An even better route would be to use one of the channels connected to a Support plan, of course.)
Resetting the builder fixed it! Thank you halfer!
Most welcome. There has been some low-level grumbling about Depot here for a while; I seem to recall that Depot is meant to offer faster builds, but my anecdotal suspicion is that it is less reliable than the other two options. I think it is fine to set your CI deploy to any of these choices.