Skip to content

test(pages): pin-staleness tripwire, chunk-closure check, deploy smoke - #128

Merged
CodeWithJuber merged 2 commits into
masterfrom
test/pages-pin-tripwire
Aug 10, 2026
Merged

test(pages): pin-staleness tripwire, chunk-closure check, deploy smoke#128
CodeWithJuber merged 2 commits into
masterfrom
test/pages-pin-tripwire

Conversation

@CodeWithJuber

Copy link
Copy Markdown
Owner

What this adds

Three checks around the jsDelivr-pinned landing chunks, closing gaps that currently ship silently with a green build:

Check Failure it catches Runs where
Closure — the pinned entry chunk's static-import graph must fully resolve inside landing/assets/ Pin names an entry that exists, but one of its chunk dependencies doesn't → SPA 404s after a green deploy Everywhere (history-free)
Tripwire — newest landing/assets/ commit must be the pin commit or its ancestor Someone commits rebuilt chunks without re-cutting the pin → deployed site serves the old build indefinitely Quality gate (fetch-depth: 0); skips shallow checkouts with an explicit message
Deploy smoke (RUN_INTEGRATION=1) — the deployed site must serve exactly the chunks the repo pins Failed/partial deploy that no in-repo check can see On demand / integration runs; fetch retried like build-pages.mjs

Why these, and not a redesign

An audit of the live site (suspected stale deployment) traced the full landing/ history: the pin at 53683ed8 matches the final 2026-07-22 chunk commit, and 5046b13 re-cut it deliberately — the site is not stale, and the leftover chunks in landing/assets/ are same-day superseded iterations. The jsDelivr-pin design is intentional (static.yml deploys only index.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)

  • Full suite: 1116 pass / 0 fail; biome check clean
  • Tripwire proven both directions against real history: a probe commit touching landing/assets/ after the pin makes it fail; current repo state passes
  • Deploy smoke passed end-to-end against the live site (RUN_INTEGRATION=1)
  • Post-push blob-hash of test/pages.test.js verified identical to the locally tested file (this caught and fixed a 2-char transcription error in the first push — see commit history)

Notes

  • The SPA-internal version string (v0.27.0 vs package.json v0.31.0) remains the documented KNOWN DEBT — unfixable from here until the landing source is committed. This PR doesn't touch it.
  • No production code, workflow, or landing assets changed; tests only.

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.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment thread test/pages.test.js
Comment on lines +231 to +233
const pinSha = landing.match(
/cdn\.jsdelivr\.net\/gh\/CodeWithJuber\/forgekit@([0-9a-f]{40})\//,
)?.[1];

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Comment thread test/pages.test.js
Comment on lines +201 to +204
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];

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Comment thread test/pages.test.js
Comment on lines +261 to +264
for (let i = 0; i < 3 && !res; i++) {
try {
res = await fetch("https://codewithjuber.github.io/forgekit/");
} catch (e) {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

@CodeWithJuber
CodeWithJuber merged commit 636fd6e into master Aug 10, 2026
12 checks passed
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.

1 participant