CI: PRs never hit the build cache (Build Cache workflow disabled + failing)

[mmcky]

Summary

Every PR runs a full, cold ~37-minute build because the global Actions cache is empty — there is never a cache hit. The restore wiring in ci.yml is correct; the problem is upstream of it: the cache is never produced. There are two independent reasons, plus one minor config nit.

Evidence

Check	Result
gh cache list	empty (no caches exist)
Recent PR CI runs	37–39 min each, log shows ⚠️ No cache found
Build Cache (cache.yml) runs	every run failed, weekly from 2026-03-23 through 2026-05-25
Build Cache runs since 2026-06-01	none
Build Cache workflow state	disabled_inactivity

Cause 1 — the Build Cache workflow is currently disabled

The Build Cache workflow state is disabled_inactivity (GitHub auto-disabled the schedule) and it has not run since 2026-05-25. While disabled, the weekly job never runs, so the cache is never (re)built regardless of anything else. It needs to be re-enabled in the Actions tab (or via gh workflow enable), then kicked once via workflow_dispatch to seed a cache.

Cause 2 — even when it ran, the build failed (so no cache was saved)

build-jupyter-cache only saves the cache when all builds pass. Every run failed on lectures/un_insure.md with a CellExecutionError, so all-passed=false and the save step was skipped — leaving the cache empty.

This is not a bug in our lecture: un_insure.md builds successfully in our PR CI on a cold build (run 27321596555, executed in 8.9s) and renders correctly on the upstream live site (https://python-advanced.quantecon.org/un_insure.html). The root cause is the unpinned numpy/scipy in the quantecon-build:latest container, already tracked in QuantEcon/actions#28. Because :latest is a moving tag, the same workflow passes or fails depending on when the image was last rebuilt — which is why our PR builds and cache builds disagree.

The reason this rotted unnoticed for months (no alert issue, no debuggable traceback in the cache path) is a set of tooling gaps tracked in QuantEcon/actions#83.

Cause 3 (minor) — builder vs builders typo in cache.yml

cache.yml line 28 passes builder: 'html', but the build-jupyter-cache input is builders (plural). The value is silently ignored; it happens to be harmless today because the default is already html, but it should be corrected to avoid a future surprise.

Suggested actions

• Re-enable the Build Cache workflow (currently disabled_inactivity) and trigger one workflow_dispatch run to seed the cache.
• Get the cache build green — depends on quantecon-build container: unpinned scipy/numpy causes CellExecutionError in un_insure.md actions#28 (container pin) and/or the upstream un_insure.md fsolve fix.
• Fix the builder: → builders: typo in cache.yml.
• Once a cache exists, confirm PR runs report a restored cache and drop well below the current ~37 min.

[mmcky]

Update: the #28 root cause is fixed upstream — only the re-enable/seed steps remain

The container root cause (Cause 2) is resolved in quantecon/actions: QuantEcon/actions#84 pinned the quantecon-build science stack to the Anaconda 2025.12 baseline (numpy=2.3.5 / scipy=1.16.3), and ghcr.io/quantecon/quantecon-build:latest was rebuilt on 2026-06-22 01:25Z. Because our workflows consume :latest, this is picked up automatically — no action-pin bump needed on our side, and the runtime now matches our declared anaconda=2025.12.

That cleared the dependency, so I've actioned the remaining operational steps:

• Re-enabled the Build Cache workflow (was disabled_inactivity, now active).
• Triggered a seed run on main: https://github.com/QuantEcon/lecture-dp/actions/runs/27924410929
• Confirm that run goes green and saves a cache (un_insure.md should now execute cleanly on the pinned container).
• Re-run an open PR's CI and confirm it reports a restored cache and drops well below ~37 min.
• Fix the builder: → builders: typo in cache.yml (Cause 3).

The tooling gaps that let this rot unnoticed (no alert, no failure report) are tracked separately in QuantEcon/actions#83.

[mmcky]

✅ Seed run is green and the cache is populated

Run 27924410929 finished success (02:19Z) on the pinned container:

• un_insure.md executed in 12.05s — no more CellExecutionError.
• ✅ html: passed → ALL BUILDS PASSED - Cache will be saved.
• gh cache list now shows two caches on main:
  • build-23d4d433…--27924410929 (88.5 MiB) — full build cache
  • jupyter-cache-057a2cf3…-27924410929 (15.1 MiB) — execution cache

PR restores prefix-match build-, so open PRs (including #26) will now get a hit on their next CI run regardless of any environment.yml hash drift. Remaining: confirm a PR run reports the restored cache + sub-37-min build, and fix the builder: → builders: typo (Cause 3).

[mmcky]

✅ Verified: PRs now hit the cache

Pushed the builder: → builders: fix (Cause 3) to #26 as 30b6d49, which triggered a fresh CI run that confirms the whole pipeline:

Run 27925870768 — success in ~2 min (cold builds were ~37):

• Cache restored from key: build-23d4d433…--27924410929 (the seed run's cache), matched via the build- prefix even though Tooling scaffolding refresh: Dependabot, linkcheck, action-pin bumps #26 edits environment.yml (requested build-87e280d9…).
• 52 notebooks served from cache, 0 re-executed — including un_insure.md (Using cached notebook: ID=51).

All three causes are now addressed: container pinned upstream (QuantEcon/actions#28), workflow re-enabled + cache seeded, and the input typo fixed. The only thing left is merging #26. Closing once that lands.

[mmcky]

Resolved. #26 merged to main (e5b342e); the merge auto-triggered a Build Cache rebuild via the environment.yml push trigger, and the weekly schedule run also went green — so the producer is healthy on both triggers. Verified PR cache hit (run 27925870768: restored cache, 52/52 notebooks cached, ~2 min vs ~37 cold). Root cause fixed upstream in QuantEcon/actions#28; remaining tooling hardening tracked in QuantEcon/actions#83.