Fix: trampoline release deploys through workflow_dispatch + smoke check

[lsequeiraa]

What

Fixes the silent-stale-prod failure mode of PR #89's dual-trigger workflow by trampolining release events through workflow_dispatch instead of deploying directly on the release event. Adds a post-deploy smoke check as a safety net for any future variant of the same class of bug.

Why (the v0.8.0 main page)

After v0.8.0 was released on 2026-06-05, prod stayed on v0.7.0. As of writing, https://JamboChen.github.io/endfield-calc/ still serves the v0.7.0 bundle index-CV_olKzG.js with last-modified: Fri, 05 Jun 2026 04:09:29 GMT. That timestamp is the bump-push run's deploy time, not the release run's 04:11:01 deploy time. Beta updated correctly.

Both runs reported success and showed pages_build_version: 74b7856c6bc1f02d9fc240e35cb524fde3981ac4 in their deploy step logs.

Root cause: actions/deploy-pages#383

The Pages backend silently drops the second deployment of a given SHA on release events specifically. actions/deploy-pages prints Reported success!, the deployments API marks the new deployment active and the prior one inactive, but the origin keeps serving the prior tarball. push and workflow_dispatch deployments at the same SHA are not affected. Per the issue thread and independent repro at typst-community/dev-builds#1:

Sequence at the same SHA	Content swaps?
push then workflow_dispatch	✅
workflow_dispatch then workflow_dispatch	✅
push then release	❌ release deploy eaten
push then release then workflow_dispatch	✅ the dispatch unsticks it

Independently confirmed on this fork: two consecutive workflow_dispatch deploys of 74b7856 (with a v0.8.0 tag pushed between them) swapped content correctly; the matching release event with 74b7856 did not.

PR #89's dual-trigger design collides on every release: the version-bump push and the matching release publish always share a SHA. So every release silently keeps prod on the previous tag.

The fix: release trampoline

GITHUB_TOKEN is explicitly permitted to trigger workflow_dispatch (documented exception to the recursive-workflow prevention rule). So release events don't deploy directly. They re-trigger this same workflow as a workflow_dispatch on the default branch:

redispatch:
  if: github.event_name == 'release'
  runs-on: ubuntu-latest
  permissions:
    actions: write
  steps:
    - name: Re-trigger deploy as workflow_dispatch
      env:
        GH_TOKEN: ${{ github.token }}
        DEFAULT_BRANCH: ${{ github.event.repository.default_branch }}
      run: gh workflow run deploy.yml --repo "$GITHUB_REPOSITORY" --ref "$DEFAULT_BRANCH"

deploy:
  if: github.event_name != 'release'
  # ... existing job unchanged

Loop-safety: the dispatched run's github.event_name is workflow_dispatch, so the trampoline's if: skips and only deploy runs. Verified on the fork (see "Validation" below).

Why not other approaches

I tried what the #383 thread discusses and a few alternatives:

• Step-level env: GITHUB_SHA: <unique> and echo GITHUB_SHA=... >> $GITHUB_ENV: the runner re-injects the real commit SHA at every step start. Submitted build_version unchanged in both attempts. Per GitHub Actions docs: "Default environment variables can't be overridden in $GITHUB_ENV."
• Direct POST /repos/{owner}/{repo}/pages/deployments via curl and gh api with explicit Accept, X-GitHub-Api-Version, Bearer/token auth, OIDC token in body, and environment: github-pages: HTTP 404 in every configuration even with pages: write scope and a GET /pages probe returning 200. Same outcome reported by the #383 author. The endpoint refuses plain GITHUB_TOKEN.
• Empty-commit recovery as the daily workflow: works but requires a manual step per release.

The trampoline is the only mechanism I found that's fully automatic, requires no extra permissions on the deploy job, and works without empty commits.

Smoke check (safety net)

A post-deploy step compares the entry-chunk filename (hash-suffixed by Vite, changes whenever source changes) in the just-built dist/index.html and dist/beta/index.html against the live URLs, with backoff to absorb CDN propagation. Walltime: ~0 to 2s on the happy path, capped at ~6 min on hard failure.

The trampoline is the fix; the smoke check is here so any future variant of stale-deploy weirdness (CDN regression, an upload-pages-artifact bug, a new SHA-keyed dedup mode, etc.) becomes a loud CI failure instead of silent prod drift.

End-to-end validation on fork

Reproduced the bug then proved the fix on lsequeiraa/endfield-calc, at fork master SHA 19bfeed628f897948e363dfdd21a2478a10a30b7:

1. Baseline push deploy (run 27349007808): redispatch skipped, deploy succeeded in 55s. Submitted pages_build_version: 19bfeed.... Live = v0.7.0 bundle index-CV_olKzG.js, last-modified: 13:08:44.
2. Tag v0.8.0 at the same SHA, publish release.
3. Release run (27349142880, 10s): redispatch ran, deploy skipped. The trampoline called gh workflow run on the default branch.
4. Auto-dispatched run (27349150683, 39s): deploy ran (built prod = v0.8.0), redispatch skipped (no recursion). Submitted pages_build_version: 19bfeed..., identical to step 1. Live = v0.8.0 bundle index-lcwJ2ad_.js, last-modified: 13:10:53, robots has Disallow: /endfield-calc/beta/. Smoke check passed.

Identical SHA, different content, both swapped. Exactly the case where deploy-pages silently fails today.

Tomorrow's v0.8.1 release walkthrough

1. Merge "Bump version to 0.8.1" PR. Push run deploys (fresh SHA): prod = v0.8.0 (current latest tag), beta = master. Smoke check passes. (This step also unsticks v0.7.0 to v0.8.0 today.)
2. Publish v0.8.1 release. Release run (~10s) trampolines through workflow_dispatch.
3. Auto-dispatched run: prod = v0.8.1, beta = master. Smoke check passes. Live prod = v0.8.1, about 90 s after the release.

Zero empty commits, zero manual steps, zero red runs.

Files

.github/workflows/deploy.yml: adds the redispatch job, guards the deploy job with if: github.event_name != 'release', adds the Smoke-test live deployment step. Inline comments cite #383 and explain the mechanism, the alternatives that don't work, and the smoke-check role.

Refs

• actions/deploy-pages#383: root cause and prior workarounds
• community#170184: discussion of pages_build_version overrides
• typst-community/dev-builds#1: independent repro of the event matrix