ci: pin and cache wasm-pack instead of curl-piping the installer - #137
Open
diegokingston wants to merge 2 commits into
Open
ci: pin and cache wasm-pack instead of curl-piping the installer#137diegokingston wants to merge 2 commits into
diegokingston wants to merge 2 commits into
Conversation
The Pages deploy for b951e69 — the merge of #131 — died on info: downloading wasm-pack curl: (22) The requested URL returned error: 503 a transient 503 from the GitHub releases CDN. `installer/init.sh` has no retry, so one bad response fails the job, and the deploy job is the whole deploy: main stayed unpublished until someone noticed by hand. CI passed on that same commit, which is exactly why it went unnoticed — the two jobs install wasm-pack identically, so CI was not more robust, only luckier. `taiki-e/install-action` fetches a prebuilt binary with retries and caches it. The repo already uses it for nextest, so this is the existing convention rather than a new dependency. It also pins the version. The script fetched whatever was current — 0.13.1 on that run — while a local checkout here had 0.14.0, so CI and developer machines were building the WASM boundary with different tools and nothing recorded it. 0.13.1 is what CI has actually been using, so this changes no behaviour; it just makes the version explicit and movable on purpose. All three sites: the deploy job and the two in ci.yml.
Same class as the wasm-pack 503 this branch already fixes: a GitHub-side transient in a step that proves nothing turns a green run red. On PR90 the e2e job printed `124 passed (7.7m)` and then failed, because `Upload Linux screenshot baselines / diffs` timed out against the artifact service — five retries, all `Request timeout: .../CreateArtifact`. The check reads as a broken branch. It is not one, and the only way to find that out is to open the log and scroll past the summary. The three upload steps are diagnostics: screenshots on a visual mismatch, Playwright traces on a failure, criterion reports for reading later. Their value is strictly less than a trustworthy pass/fail signal, so they now carry `continue-on-error: true`. The pattern is already in this file — the criterion benchmark run above uses it for the same reason. This does mean a genuinely broken upload goes quiet. That is the trade being made, and it is the right way round: the tests have already reported.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What happened
The Pages deploy for
b951e694— the merge of #131 — failed:A transient 503 from the GitHub releases CDN. Nothing to do with what #131 changed.
The consequence was larger than the cause: the deploy job is the deploy, so
mainsat unpublished — Education and the landing copy that shipped with it were merged but not live — until it was noticed by hand. There is no retry and no alert, so the gap is however long it takes someone to look.CI passed on that same commit, which is precisely why it went unnoticed. Both workflows install wasm-pack with the same
curl … | sh, so CI was not more robust than the deploy — it was luckier.The fix
taiki-e/install-actionfetches a prebuilt binary with retries and caches it. The repo already uses this action for nextest (ci.yml:53,ci.yml:121), so this follows the existing convention rather than adding a dependency.Applied to all three install sites: the deploy job and both in
ci.yml.It also pins the version, which the installer script did not — it fetched whatever was current. That run got 0.13.1; a local checkout here had 0.14.0, so CI and developer machines were building the WASM boundary with different tools and nothing in the repo recorded which. Pinning to 0.13.1 is what CI has actually been using, so this changes no build behaviour; it makes the version explicit and moves it on purpose instead of by drift.
Verification
The failed deploy was re-run and succeeded, which confirms the 503 was transient and the site is live again at
b951e694. This PR is about the next one.I could not parse-check the YAML locally (no PyYAML, no actionlint on this machine) — CI on this PR is the check. The change is confined to replacing a
run:step with a pinneduses:step in three places; it introduces no expression interpolation and so no injection surface.What this does not fix
A failed deploy is still silent. Nothing notifies when
mainstops publishing, so the failure mode — merged but not live — depends on someone checking. Worth a follow-up if it recurs.