install.sh grew a retry loop, per-command timeouts and a deliberately
non-gating apt-get update after this runner pool cost several whole runs: a
mirror going silent for two hours, and a Hash Sum mismatch from a third-party
repository the project does not even use turning builds red. Those lessons were
local to that one file.
install_riscv.sh had none of them, and #717 puts it on every pull request's
critical path. Under set -e its bare apt-get update was a single point of
failure for the whole suite -- the precise case install.sh downgrades to a
warning on purpose -- and its two wget calls, each fetching about 500 MB, had
no retry and no timeout.
Rather than copy the helpers and let them drift again, they move to
tx_ci_common.sh and both scripts source it, following the arrangement
scripts/tx_windows_common.ps1 already uses on the Windows side. install.sh
keeps its behaviour exactly: same APT_OPTIONS, same 120-second TIMEOUT, same
three-attempt retry, and the comments explaining each of them travel with the
code they explain.
Two things are new:
- TIMEOUT_LONG, 180 seconds, for a single large download. Sized against the
39 seconds each tarball took on 10 Sep 2026 and deliberately not larger:
the install step is capped at ten minutes, and a per-attempt timeout able
to swallow that cap would leave the retry loop no turn to take, which is
the failure mode the apt comment already records.
- fetch(), which verifies a SHA-256 before anything is unpacked. Both digests
were taken from the releases API and then checked against the bytes the CDN
actually serves. This is not an independent trust root -- expected value and
file come from the same host -- but it pins the bytes, so a deleted and
re-pushed tag or a replaced asset stops the build instead of being picked up
silently.
Also verifies qemu-system-riscv32 alongside riscv64. run.sh selects one per
architecture, so both are worth failing on here rather than at the first test.
Verified locally: retry returns 0 on success and 1 after three attempts;
fetch accepts a correct digest and, on a wrong one, fails and removes the
partial file; the source line resolves from the repository root, from an
absolute path and through a symlink; and both recorded digests match the
bytes served for the pinned tag.
Assisted-by: Claude Code (Opus 5) <noreply@anthropic.com>
