Finding (2026-09-01, D4 post-merge sweep)
casket-pages.yml (name: GitHub Pages) has zero successes in its last ~93 runs: 47 cancelled + 46 failure. Found while sweeping the D4 merge (#73, 1ac7e41) for startup_failures — the lockfile is NOT implicated (run passed startup validation; checkout/GHCup/cache steps all succeeded).
Two failure eras
- Through 2026-05-30 (46 ×
failure): build completed, then the Setup Pages step (actions/configure-pages) failed — most recent example run 26690930686 @ 3255a65. Consistent with the Pages site not being enabled for the repo.
- Since then (47 ×
cancelled): the Build casket-ssg step (cabal build of hyperpolymath/casket-ssg checked out fresh each run) is killed by the job's timeout-minutes: 15. Latest: run 33566033230 @ 1ac7e41 — queued 12 min, build killed at 15m16s.
Why it matters
Same disease class as quality-gates before #66: a workflow that is red on every push to main is noise, and rot compounds behind it (sitrep docs/sitrep-2026-09-01.adoc).
Remediation options (owner pick)
- Raise
timeout-minutes on the build job (a cold GHC/cabal build of casket-ssg plausibly needs 25–40 min) — cheapest, proves whether the cache ever gets warm; once one run completes, actions/cache should make later runs fast.
- Check the cache never restores: key is
hashFiles('.casket-ssg/casket-ssg.cabal') but no run has ever reached the cache-save phase with a finished build, so the cache is likely empty — a first successful (long-timeout or manual) run would seed it.
- Verify Pages is enabled for the repo before burning build minutes (the pre-May failure mode) — else even a finished build fails at Setup Pages again.
- Or disable the workflow like pages.yml/instant-sync.yml (
disabled_manually) if the casket-ssg site is not wanted here.
Note: lock entries for this workflow are proven at startup; if the workflow is instead disabled, the entries stay valid and inert.
🤖 Generated with Claude Code
Finding (2026-09-01, D4 post-merge sweep)
casket-pages.yml(name: GitHub Pages) has zero successes in its last ~93 runs: 47 cancelled + 46 failure. Found while sweeping the D4 merge (#73,1ac7e41) for startup_failures — the lockfile is NOT implicated (run passed startup validation; checkout/GHCup/cache steps all succeeded).Two failure eras
failure): build completed, then the Setup Pages step (actions/configure-pages) failed — most recent example run 26690930686 @3255a65. Consistent with the Pages site not being enabled for the repo.cancelled): the Build casket-ssg step (cabal buildof hyperpolymath/casket-ssg checked out fresh each run) is killed by the job'stimeout-minutes: 15. Latest: run 33566033230 @1ac7e41— queued 12 min, build killed at 15m16s.Why it matters
Same disease class as quality-gates before #66: a workflow that is red on every push to main is noise, and rot compounds behind it (sitrep
docs/sitrep-2026-09-01.adoc).Remediation options (owner pick)
timeout-minuteson the build job (a cold GHC/cabal build of casket-ssg plausibly needs 25–40 min) — cheapest, proves whether the cache ever gets warm; once one run completes,actions/cacheshould make later runs fast.hashFiles('.casket-ssg/casket-ssg.cabal')but no run has ever reached the cache-save phase with a finished build, so the cache is likely empty — a first successful (long-timeout or manual) run would seed it.disabled_manually) if the casket-ssg site is not wanted here.Note: lock entries for this workflow are proven at startup; if the workflow is instead disabled, the entries stay valid and inert.
🤖 Generated with Claude Code