Transient failure accessing nugets redirects CoreCLR build to a broken backup link

[dingydandy]

Initial cost estimate: 2 days
Initial contacts: @trylek, @ViktorHofer

I get coreclr source code from https://github.com/dotnet/runtime.git, the master branch, and I want to biuld the source code, so I run build.cmd, however, I get the following feedback:
E:\Code\netcore src\coreclr>.\build.cmd
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-rc.1.20454.5/dotnet-sdk-5.0.100-rc.1.20454.5-win-x64.zip
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-rc.1.20454.5/dotnet-sdk-5.0.100-rc.1.20454.5-win-x64.zip
dotnet-install: Downloading legacy link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-rc.1.20454.5/dotnet-dev-win-x64.5.0.100-rc.1.20454.5.zip
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-rc.1.20454.5/dotnet-dev-win-x64.5.0.100-rc.1.20454.5.zip
Failed to install dotnet from public location.
Some builds failed:
Configuration: Debug, Architecture: x64

So, what's wrong, can anyone tell me how to build the coreclr cource code? I need help.

[trylek] Based on below discussion I believe that the actionable work item here is making sure we don't resort to a broken backup link when the main nuget link is broken and instead we display a sufficiently descriptive error message.

[EgorBo]

Are you under some proxy?

[dingydandy]

@EgorBo No, I tried without proxy, still not work, however, when I paste the url https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-rc.1.20454.5/dotnet-dev-win-x64.5.0.100-rc.1.20454.5.zip, I get the following errors:

it seams that the blob does not exists

[trylek]

Hmm, just tried that and now it seems to be working for me; to be precise, I'm not hitting the first download failure so I'm not observing runtime build resorting to the fallback link that is indeed broken. @dingydandy - in your previous response you demonstrated that the "fallback link" doesn't work (I concur, it doesn't work for me either); but the primary link does work for me - can you please clarify whether the primary link,

https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-rc.1.20454.5/dotnet-sdk-5.0.100-rc.1.20454.5-win-x64.zip

is still inaccessible for you or whether that was just a transient issue (so that you're now unblocked w.r.t. running "build" in your clone of the runtime repo)? @ViktorHofer, have you got any idea where the malfunctioning backup link,

https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-rc.1.20454.5/dotnet-dev-win-x64.5.0.100-rc.1.20454.5.zip

is coming from? I don't see the value in resorting to a broken backup link if the primary link doesn't work but I have no idea where this should be fixed.

@dingydandy - just as a heads-up, the snippet in the issue title seems to indicate that the folder with your clone of the runtime repo is on a path containing spaces; a new issue was filed last week by someone who found out that parts of runtime build got broken in this scenario (it worked several months back but has apparently bit-rotten):

#42397

Thanks

Tomas

[trylek]

@dingydandy - Hmm, rereading the issue description I think I may have slightly misunderstood the steps - upon a second glance it looks like your location of the runtime repo clone is actually E:\Code\netcore and you're trying to run build.cmd in the folder src\coreclr - but that script is no longer there, the only remaining script there is build-runtime.cmd as CoreCLR is supposed to be built using the root build script i.e. something like

E:\Code\netcore>build clr

Can you please double-check how old runtime repo clone you're using and / or retry with a fresh clone of the runtime repo in a different folder? Alternatively, please double-check whether you don't have stale artifacts in the repo clone or use git clean -xdf to get rid of them.

[ViktorHofer]

Closing in favor of #34015 which tracks improving the SDK bootstrap scripts.