Skip to content

ci(tinygo): pin wasmtime and verify it landed on PATH - #685

Open
mparrett wants to merge 1 commit into
mainfrom
wt/ci-pin-wasmtime
Open

ci(tinygo): pin wasmtime and verify it landed on PATH#685
mparrett wants to merge 1 commit into
mainfrom
wt/ci-pin-wasmtime

Conversation

@mparrett

@mparrett mparrett commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator

tinygo-wasi-build could fail on a PR that touched nothing related to TinyGo, and blame the wrong step while doing it. #682 has the full trace; the short version is that install.sh resolves "latest" by sed-ing tag_name out of an unauthenticated GitHub API response. When that call is rate-limited the sed yields a literal {, the download 404s, and the script still exits 0. The install step stayed green, and the job died two steps later at wasmtime run with command not found — attributed to Boot past the reflect shim (must not trap), which reads as a real TinyGo regression.

Two changes, both in the tinygo-wasi-build job:

  • Pin the version. --version v47.0.3 sends the installer down its specific-version branch, which never calls the GitHub API, so the failure mode is gone rather than reported better. This also matches Install TinyGo directly above, which has always pinned (v0.41.1).
  • Verify after install. wasmtime --version as its own step, since GITHUB_PATH only affects later steps. A bad install now fails at the install, not two steps downstream.

Verified the pinned path end to end: the installer takes --version and downloads that archive with no API call, and the v47.0.3 linux asset the workflow fetches returns 200.

v47.0.3 is current as of 2026-07-31. Pinning does mean someone bumps it eventually; that seems right for a job whose purpose is proving our TinyGo build boots past the reflect shim, not tracking wasmtime releases. If you want tip coverage it belongs in a scheduled job, not a per-PR gate that can go red on an unrelated PR.

install.sh resolves "latest" by sed-ing tag_name out of an
unauthenticated GitHub API response. When that call is rate-limited the
sed yields a literal `{`, the download 404s, and the script still exits
0 — so the job stayed green through install and died two steps later at
`wasmtime run` with `command not found`, attributed to the reflect-shim
boot check. Pinning skips the API lookup entirely; the verify step makes
a bad install fail where it happens.

Closes #682

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@mparrett
mparrett requested review from nnunley and nooga August 6, 2026 03:38
@nnunley

nnunley commented Aug 10, 2026

Copy link
Copy Markdown
Collaborator

Confirmed the mechanism rather than assuming it: install.sh does take --version, the
v47.0.3 tag resolves, and the verify step is a separate step so the $GITHUB_PATH append
from the previous one has actually taken effect — it is a real check, not a tautology.
Turning a rate-limited API into an attributable failure at the install step instead of a
command not found two steps later is worth the eight lines.

Only nit: the version is a literal in the workflow, like the TinyGo pin above it, so a future
bump touches two places. Fine at this size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants