ci(web): add precise wasm-freshness gate; drop flawed drift heuristic #93

2026-06-22T19:03:20Z

funman300 commented

2026-06-22 19:03:20 +00:00

Why

The web build shipped a ~3-week-stale pkg/ (fixed in #92). The existing "Check wasm pkg drift" step in docker-build.yml should have caught it but didn't: it only hard-failed on direct solitaire_web/ edits, and treated solitaire_engine/ + solitaire_core/ changes as a non-blocking notice. The card_game migration's churn lived almost entirely in engine/core/data (plus the v4→v5 save schema), so it sailed through.

What

A dedicated web-wasm-freshness workflow that rebuilds the artifacts and diffs them against what's committed — the precise check, not a changed-files heuristic.

A fresh build on a pinned toolchain is byte-for-byte reproducible (verified locally: rebuild → empty git status on pkg/). Pins: rust 1.95.0, wasm-bindgen 0.2.120, wasm-pack 0.14.0, binaryen 130 (the wasm-opt version matters — it's applied to canvas_bg.wasm).
No false positives on wasm-irrelevant edits (comments, tests, desktop/android-only code) — it only fails when the rebuilt bytes actually differ.
No false negatives on logic-only drift that doesn't change the JS API (e.g. the save-schema change the old heuristic missed).
Runs on pull_request as well as master push, so staleness is blocked before merge.

The superseded heuristic is removed from docker-build.yml; master stays fresh via the PR gate, so the deploy image always builds from current artifacts.

Note

First CI run validates the pinned action/tool availability on the runner. The binaryen 130 asset URL was confirmed reachable (HTTP 200). When the artifacts are next regenerated with a newer toolchain, bump the four version pins in the workflow in lockstep.

🤖 Generated with Claude Code

## Why The web build shipped a ~3-week-stale `pkg/` (fixed in #92). The existing "Check wasm pkg drift" step in `docker-build.yml` should have caught it but didn't: it only **hard-failed** on direct `solitaire_web/` edits, and treated `solitaire_engine/` + `solitaire_core/` changes as a non-blocking **notice**. The card_game migration's churn lived almost entirely in engine/core/data (plus the v4→v5 save schema), so it sailed through. ## What A dedicated **`web-wasm-freshness`** workflow that **rebuilds the artifacts and diffs them** against what's committed — the precise check, not a changed-files heuristic. - A fresh build on a **pinned toolchain** is byte-for-byte reproducible (verified locally: rebuild → empty `git status` on `pkg/`). Pins: `rust 1.95.0`, `wasm-bindgen 0.2.120`, `wasm-pack 0.14.0`, `binaryen 130` (the wasm-opt version matters — it's applied to `canvas_bg.wasm`). - **No false positives** on wasm-irrelevant edits (comments, tests, desktop/android-only code) — it only fails when the rebuilt bytes actually differ. - **No false negatives** on logic-only drift that doesn't change the JS API (e.g. the save-schema change the old heuristic missed). - Runs on **`pull_request`** as well as master push, so staleness is blocked **before** merge. The superseded heuristic is removed from `docker-build.yml`; master stays fresh via the PR gate, so the deploy image always builds from current artifacts. ## Note First CI run validates the pinned action/tool availability on the runner. The binaryen 130 asset URL was confirmed reachable (HTTP 200). When the artifacts are next regenerated with a newer toolchain, bump the four version pins in the workflow in lockstep. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

funman300 added 1 commit 2026-06-22 19:03:20 +00:00

ci(web): add precise wasm-freshness gate; drop flawed drift heuristic

Web WASM Freshness / freshness (pull_request) Failing after 7m14s

Details

43076a48d6

The web build shipped a ~3-week-stale pkg/ because the old "Check wasm pkg
drift" step in docker-build.yml only hard-failed on direct solitaire_web/
edits and treated solitaire_engine/_core changes as a non-blocking notice —
so the entire card_game migration (engine/core/data churn, v4->v5 save
schema) slipped through.

Replace it with a dedicated `web-wasm-freshness` workflow that rebuilds the
artifacts and diffs them against what's committed. A fresh build on a pinned
toolchain (rust 1.95.0 / wasm-bindgen 0.2.120 / wasm-pack 0.14.0 / binaryen
130) is byte-for-byte reproducible — verified locally — so this is precise:
it fails on *any* real drift (including gameplay-logic changes that don't
touch the JS API surface) and has no false positives on wasm-irrelevant edits.
Runs on pull_request as well as master push, so staleness is caught before
merge rather than only blocking the post-merge deploy.

Remove the superseded heuristic from docker-build.yml; master stays fresh via
the PR gate, so the deploy image is always built from current artifacts.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

funman300 merged commit da165f1622 into master

2026-06-22 19:03:50 +00:00

funman300 referenced this issue from a commit

2026-06-23 16:35:14 +00:00

fix(web): make wasm builds reproducible so the freshness gate passes

funman300 referenced this pull request

2026-06-23 16:35:32 +00:00

fix(web): CI-owned wasm artifacts + e2e harness fixes #95

funman300 referenced this issue from a commit

2026-06-23 17:00:13 +00:00

ci(web): replace wasm freshness gate with CI-side rebuild-and-commit

Sign in to join this conversation.