chore(ci): Make the install scripts fail on a bad download instead of a checksum mismatch

[skartikey]

The three scripts that download a toolchain tarball call curl without --fail, so an HTTP error response is written to the output file and curl exits 0. The checksum check that follows then fails, and the job reports Checksum failed for what was really a 503 from the download host.

• scripts/install_gotestsum.sh line 22
• scripts/installgo_linux.sh line 13
• scripts/installgo_mac.sh line 26

None of them pass --retry either, so a transient blip on github.com or go.dev fails the job outright rather than being ridden out.

What it looked like

During a GitHub download outage on 2026-08-12 around 19:40 UTC this failed six pull requests in a row, on whichever job happened to be running. Two different symptoms, one cause:

test-go-linux-386 (job 544263) downloaded 107 bytes instead of the tarball and reported:

+ curl -L https://github.com/gotestyourself/gotestsum/releases/download/v1.13.0/gotestsum_1.13.0_linux_amd64.tar.gz --output gotestsum.tar.gz
100   107  100   107    0     0   3102      0
+ sha256sum --check -
gotestsum.tar.gz: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
Checksum failed

test-go-linux (job 544215, job 544237) lost the connection outright:

curl: (56) Connection died, tried 5 times before giving up

The first one is the misleading case. Checksum failed on a pinned, long-stable release reads like a tampered or rotated artifact, which is the one thing that would justify stopping everything and looking. It cost a while to work out that the 107-byte "tarball" was an error page.

Why it is only a diagnosability problem

All three scripts verify the sha256 before extracting, so a bad download is never used. This is not a supply-chain hole, it is a confusing failure mode plus avoidable flakiness.

Suggested fix

Add --fail so an HTTP error is an error, and --retry so a transient one is retried:

curl --fail --retry 3 --retry-delay 5 -L "<url>" --output "<file>"

scripts/install_incus.sh already uses curl -fsSL, so --fail is the existing convention in this directory.

Verified locally against a server returning 503, with curl 8.7.1:

invocation	exit	output file
curl -L --output f (today)	0	58 bytes of error page
curl -fL --output f	22	not created
curl -fL --retry 2 --retry-delay 1 --output f	22 after 2s	not created

The last row confirms --retry does treat 503 as transient and retries it, so the outage above would most likely have been ridden out rather than failing six pull requests.

Out of scope

The test-go-windows failures in the same window came from choco install mingw hitting a 503 for the mingw-builds release asset. That download belongs to Chocolatey's own install script, not to anything in this repository.