CI has no build cache to restore — every PR's preview fails at the cache-download step

[mmcky]

Found while landing #12 (2026-08-19): the preview job failed with ##[error]no matching workflow run found with any artifacts at its dawidd6 cache-download step, and the cause is structural — this repo has no cache.yml workflow at all (workflows present: ci/publish only), so there is never a build-cache artifact to restore. Every PR's CI is red for this pre-existing reason regardless of the change (the Netlify deploy-preview itself built fine on #12), which trains reviewers to merge over a red check.

Also downstream of this: the site cannot surface #12's fixes (the dataBHS repoint + usetex guards in the downloadable five_preferences.ipynb) until a publish succeeds, so the publish path needs the same look.

Options, roughly in order: add a cache.yml on the family pattern (weekly cron + dispatch, upload _build as build-cache); or make the cache download tolerant (if_no_artifact_found: warn) so CI builds from scratch — slower but honest; or wait for the QuantEcon/actions migration, where restore-jupyter-cache handles the missing-cache case — see QuantEcon/actions#160 for the cache-mode decision that migration should land with.

🤖 Generated with Claude Code

[mmcky]

The structural cause recorded here does not hold up, and correcting it changes what this issue is waiting for. Measured during an independent validation of the settle week (QuantEcon/workspace-lectures#51).

This issue states that "this repo has no cache.yml workflow at all (workflows present: ci/publish only), so there is never a build-cache artifact to restore". Measured on origin/main:

• .github/workflows/ holds cache.yml, ci.yml, linkcheck.yml and publish.yml. cache.yml was added 2024-01-17 (5e4f0e3) and last touched 2024-01-22 (6824176).
• The API lists it as active: workflow id 82645084, "Build Cache [using jupyter-book]".
• It triggers on push to main, uploads artifact build-cache from _build, and both ci.yml:41 and publish.yml consume it via dawidd6/action-download-artifact@v3 with workflow: cache.yml, branch: main, name: build-cache.
• It ran and succeeded on five_preferences: read dataBHS from data-lectures, guard usetex for Colab #12's merge, at 2026-08-19T04:03:58Z on sha e1d01560, producing artifact build-cache id 9351913762 — 34,651,716 bytes, created 2026-08-19T04:08:46Z, expires 2026-11-17T04:03:58Z, expired: false.

The actual cause of #12's red preview was artifact expiry, not absence. The previous push to main was 2024-06-13 (f7489ac7), so the newest build-cache at the time was roughly 26 months old against GitHub's 90-day retention — there was nothing to download, and dawidd6@v21's silent stale-cache fallback makes that failure mode look structural.

Two consequences:

• Option 1 in this issue — add a cache.yml on the family pattern — is a no-op, and a future session would spend a PR discovering that.
• More usefully, a fresh unexpired build-cache now exists, so the publish path should work today. QuantEcon/workspace-lectures#50 defers a tools-techniques publish on the premise recorded here. If that premise is the only thing holding it, five_preferences: read dataBHS from data-lectures, guard usetex for Colab #12's dataBHS repoint and its two usetex guards could be surfaced to readers by tagging publish*, with no cache work at all.

Worth confirming before acting on it: the published site still serves the pre-#12 notebook — /_notebooks/five_preferences.ipynb is Last-Modified 2024-06-13 and still carries loadmat and usetex=True, as does the generated mirror at lecture-tools-techniques.notebooks. Both clear on the next publish.