Repository navigation
Clarify that 404 at "downloading legacy link" in dotnet-install.sh is usually expected #11
Description
When builds fail with issues like this, there's a huge red herring:
Trying to run 'curl https://dot.net/v1/dotnet-install.sh -sSL --retry 10 --create-dirs -o /__w/1/s/.dotnet/dotnet-install.sh' for maximum of 5 attempts.
Ran 'curl https://dot.net/v1/dotnet-install.sh -sSL --retry 10 --create-dirs -o /__w/1/s/.dotnet/dotnet-install.sh' successfully.
dotnet_install: Warning: Unable to locate zlib. Probable prerequisite missing; install zlib.
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.3.20168.11/dotnet-sdk-5.0.100-preview.3.20168.11-linux-x64.tar.gz
curl: (56) GnuTLS recv error (-9): A TLS packet with unexpected length was received.
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.3.20168.11/dotnet-sdk-5.0.100-preview.3.20168.11-linux-x64.tar.gz
dotnet-install: Downloading legacy link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.3.20168.11/dotnet-dev-ubuntu.16.04-x64.5.0.100-preview.3.20168.11.tar.gz
curl: (22) The requested URL returned error: 404 Not Found
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.3.20168.11/dotnet-dev-ubuntu.16.04-x64.5.0.100-preview.3.20168.11.tar.gz
dotnet_install: Error: Could not find/download: `.NET Core SDK` with version = 5.0.100-preview.3.20168.11
dotnet_install: Error: Refer to: https://aka.ms/dotnet-os-lifecycle for information on .NET Core support
The error here is curl: (56) GnuTLS recv error (-9). But, people see the 404 for the legacy download and sometimes miss the main problem, think the 404 might be a related problem, or that they have a secondary problem to look into also.
The message should clarify that the legacy download link is not a backup. (This is a typical interpretation.)
Or, can we remove the legacy fallback? What versions actually use it (are they EOL)?
Metadata
Metadata
Assignees
Labels
No labels
Activity
dsplaisted commentedon Apr 9, 2020
@marcpopMSFT this should go to Bekir for triage, but I don't know his GitHub handle
marcpopMSFT commentedon Apr 21, 2020
@dsplaisted it's @bozturkMSFT
donJoseLuis commentedon May 4, 2020
the 2nd link is already dead, thus it results in a 404, as mentioned.
dagood commentedon May 4, 2020
Maybe you're already aware, but I want to make sure this is considered appropriately. We'd need to be sure nobody is using (or plans to use) a version of the SDK that uses the legacy link rather than the new style of link. That's why I focused the issue on the misleading messaging rather than asking the link to be removed. (If we can stop supporting the legacy link, that would be good, but I have my doubts.)
How does this help the scenario I'm pointing at here? Are you expecting a user of the script to have access to the telemetry and dashboards, or is there some other scenario being looked at here?
Lack of retries seems like a separate issue about script reliability, not related to misleading log messages.
/cc @dleeapho @MichaelSimons @NikolaMilosavljevic @leecow @rbhanda
bekir-ozturk commentedon May 5, 2020
A similar issue: dotnet/sdk#10450
@johnbeisner wrote:
Let's track them both here. I am closing the other.
donJoseLuis commentedon May 26, 2020
The need tracked in this issue should be a requirement in the re-engineering effort. Moving to the re-engineering project.
issue dotnet#11: handle http status code 404 separately
issue dotnet#11: handle http status code 404 separately
Fix exceptions' handling (#110)
AR-May commentedon Dec 3, 2020
Changed the messages such that if we have 404-NotFound and some other error, the other (actual) error will be displayed at the end of the log as an error. However, the messages concerning legacy link download attempt and failure stay as info messages.