Fallback to nightly builds (ci.dot.net) is not good behavior

[pavel-purma]

trafficstars

Current behavior of the install script downloads from CDN and as fallback it tries to download from nightly build domain (ci.dot.net). That seems to be not correct behavior.

Possibly we could try directly specific another (backup) CDN

[richlander]

I think we got into a bad design point where we have one install script for internal and external uses. The one that exists today is effectively the internal one. I'd like to see a new install script with all the fallback logic removed, with knowledge of only our production/stable download domain (builds.dotnet.microsoft.com).

dotnet-install: The resource at legacy link 'https://builds.dotnet.microsoft.com/dotnet/Sdk/9.0.201/dotnet-dev-osx-arm64.9.0.201.tar.gz' is not available.
dotnet-install: Attempting to download using primary link https://ci.dot.net/public/Sdk/9.0.201/dotnet-sdk-9.0.201-osx-arm64.tar.gz
curl: (56) The requested URL returned error: 404
dotnet-install: The resource at primary link 'https://ci.dot.net/public/Sdk/9.0.201/dotnet-sdk-9.0.201-osx-arm64.tar.gz' is not available.
dotnet-install: Attempting to download using legacy link https://ci.dot.net/public/Sdk/9.0.201/dotnet-dev-osx-arm64.9.0.201.tar.gz
curl: (56) The requested URL returned error: 404

The fact that users are seeing ci.dot.net in these logs is bad. That domain is no secret. It's not that. It's that our CI server is involved in production scenarios. It should not be.

From: https://github.com/dotnet/core/issues/9797

[mmitche]

I don't think this is an internal vs. external issue. Maybe more of a contributor vs. non-contributor issue. Daily builds are required for building most .NET repos. in the current in-development band.

[richlander]

If we removed the fallback from the primary public script, couldn't we remove our dependency on aka.ms?

[mmitche]

Not really. aka.ms is used for getting the latest builds. It ends up being critical to storage account immutability