tinygo-wasi-build can go red on a PR that changed nothing related to TinyGo, and the reported failure points at the wrong step.
Seen on run 30875299785 (2026-08-04, on #628 at e21014a7). The Install wasmtime step logged a failure and still passed:
Installing latest version of Wasmtime ({)
Checking for existing Wasmtime installation
Fetching archive for Linux, version {
curl: (3) nested brace in URL position 75:
https://github.com/bytecodealliance/wasmtime/releases/download/{/wasmtime-{-x86_64-linux.tar.xz
Error: Could not download Wasmtime version '{'.
install.sh failed to resolve "latest" and interpolated a literal { into the download URL. It printed Error: and exited 0, so the step was green. Two steps later:
wasmtime: command not found
##[error]Process completed with exit code 127
The job is attributed to Boot past the reflect shim (must not trap), so it reads as "this PR broke the TinyGo boot" — the exact regression that check exists to catch. The TinyGo build itself succeeded; only the wasm runtime was missing.
It passed on a re-run with no changes, and .github/workflows/go.yml is byte-identical between the two bases I compared (1f281df4 and 6f75229d), so the failure is transient and upstream, not in the repo. The cost is the misattribution: it lands on whichever PR is in flight.
Two fixes, either of which is enough:
- Pin the version. The
Install TinyGo step directly above already does this (v0.41.1 via wget + dpkg), so pinning wasmtime the same way makes the job consistent and removes the "latest" resolution that failed here.
- Verify after install. A
wasmtime --version line in the install step makes a failed install fail where it happened, rather than two steps later.
I can send the pin as a PR if that shape sounds acceptable.
tinygo-wasi-buildcan go red on a PR that changed nothing related to TinyGo, and the reported failure points at the wrong step.Seen on run 30875299785 (2026-08-04, on #628 at
e21014a7). TheInstall wasmtimestep logged a failure and still passed:install.shfailed to resolve "latest" and interpolated a literal{into the download URL. It printedError:and exited 0, so the step was green. Two steps later:The job is attributed to
Boot past the reflect shim (must not trap), so it reads as "this PR broke the TinyGo boot" — the exact regression that check exists to catch. The TinyGo build itself succeeded; only the wasm runtime was missing.It passed on a re-run with no changes, and
.github/workflows/go.ymlis byte-identical between the two bases I compared (1f281df4and6f75229d), so the failure is transient and upstream, not in the repo. The cost is the misattribution: it lands on whichever PR is in flight.Two fixes, either of which is enough:
Install TinyGostep directly above already does this (v0.41.1viawget+dpkg), so pinning wasmtime the same way makes the job consistent and removes the "latest" resolution that failed here.wasmtime --versionline in the install step makes a failed install fail where it happened, rather than two steps later.I can send the pin as a PR if that shape sounds acceptable.