test(pages): pin-staleness tripwire, chunk-closure check, deploy smoke - #128
Conversation
Three gaps around the jsDelivr-pinned landing chunks that previously shipped silently with a green build: - closure: pinned entry chunk's static-import graph must fully resolve inside landing/assets (a pinned entry + missing dependency 404s the SPA) - tripwire: newest landing/assets commit must be the pin commit or its ancestor — committing rebuilt chunks without re-cutting the pin now fails the quality gate (needs fetch-depth: 0; skips shallow checkouts) - smoke (RUN_INTEGRATION=1): the deployed site must serve exactly the chunks the repo pins, with retried fetch matching build-pages.mjs Verified locally: full suite 1116 pass / 0 fail, biome clean, tripwire proven in both directions against real history.
Two pre-existing lines gained a stray ')' in the previous commit's regexes (caught by post-push blob-hash verification against the locally tested file). Restores the exact verified content.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 37be61d30a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const pinSha = landing.match( | ||
| /cdn\.jsdelivr\.net\/gh\/CodeWithJuber\/forgekit@([0-9a-f]{40})\//, | ||
| )?.[1]; |
There was a problem hiding this comment.
Validate every pinned SHA against asset history
This extracts only the first jsDelivr SHA, which is currently the script pin, although the page has three independently editable pinned URLs. If rebuilt assets are committed and the script URL is updated while either CSS URL accidentally retains its old SHA, newestAssets is an ancestor of pinSha and this tripwire passes even though production continues serving stale CSS. Check every extracted pin or assert that all pins use the same validated SHA.
Useful? React with 👍 / 👎.
| const entry = pins.find((f) => /^index-.*\.js$/.test(f)); | ||
| assert.ok(entry, "landing pins exactly one entry chunk"); | ||
| const seen = new Set(); | ||
| const queue = [entry]; |
There was a problem hiding this comment.
Include pinned CSS in the closure walk
The test says it walks from the entry and pinned CSS, but the queue contains only the JavaScript entry and CSS files are never parsed. If a future pinned stylesheet adds a relative @import or url(...) dependency that is absent from landing/assets, this check remains green while browsers receive a 404 for that dependency. Seed the walk with all pinned assets and inspect relative CSS dependencies as well.
Useful? React with 👍 / 👎.
| for (let i = 0; i < 3 && !res; i++) { | ||
| try { | ||
| res = await fetch("https://codewithjuber.github.io/forgekit/"); | ||
| } catch (e) { |
There was a problem hiding this comment.
Retry transient HTTP failures in the deploy smoke
A resolved HTTP 429 or 5xx response assigns res, terminates the loop because !res becomes false, and fails immediately at the later res.ok assertion. Thus transient Pages/CDN responses still masquerade as deploy failures despite the stated retry guarantee; the referenced helper in scripts/build-pages.mjs:116-117 throws on every non-OK response so its catch loop retries them. Treat non-OK responses as retryable inside this loop too.
Useful? React with 👍 / 👎.
What this adds
Three checks around the jsDelivr-pinned landing chunks, closing gaps that currently ship silently with a green build:
landing/assets/landing/assets/commit must be the pin commit or its ancestorfetch-depth: 0); skips shallow checkouts with an explicit messageRUN_INTEGRATION=1) — the deployed site must serve exactly the chunks the repo pinsbuild-pages.mjsWhy these, and not a redesign
An audit of the live site (suspected stale deployment) traced the full
landing/history: the pin at53683ed8matches the final 2026-07-22 chunk commit, and5046b13re-cut it deliberately — the site is not stale, and the leftover chunks inlanding/assets/are same-day superseded iterations. The jsDelivr-pin design is intentional (static.yml deploys onlyindex.html), so this PR hardens the design instead of replacing it.The residual real gap: nothing failed CI if a pin ever did drift from the newest chunks. Now it does.
Verification (all local, before push)
biome checkcleanlanding/assets/after the pin makes it fail; current repo state passesRUN_INTEGRATION=1)test/pages.test.jsverified identical to the locally tested file (this caught and fixed a 2-char transcription error in the first push — see commit history)Notes
v0.27.0vspackage.jsonv0.31.0) remains the documented KNOWN DEBT — unfixable from here until the landing source is committed. This PR doesn't touch it.