CI: cache downloaded test data so a public.esss.dk outage does not fail every run #1365

On 2026-10-08 public.esss.dk did not resolve from GitHub runners. Every test run failed, including the main nightly (12 failed, 4 errors) and every open PR, because tests download essreduce/essspectroscopy data from that server on each run. Affected: DREAM powder reduction, the BIFROST Q-maps (McStas file), ESTIA reflectometry (McStas file), the monitor workflow wavelength-mode tests, and the workflow roundtrip tests for those specs.

ci.yml caches pip only. Caching the pooch directories in the test jobs would make an outage harmless once the cache is warm:

• ~/.cache/ess (essreduce, essdiffraction, essspectroscopy, essestia data)
• ~/.cache/esslivedata (geometry artifacts from the geometry-v0 release)

pooch verifies each file against its registry hash, so a stale cache entry is re-downloaded rather than used. A key on the lock/requirements files with a broad restore-keys fallback would keep the cache warm across dependency bumps.

First step: avoid the downloads

Before adding a cache, check which tests need public.esss.dk data at all. Candidates:

• Monitor workflow wavelength-mode tests and the workflow roundtrip tests: these fetch file-based wavelength LUT tables, which are being migrated away from. They may need no download once the migration lands, or can use a small synthetic table.
• DREAM powder, BIFROST Q-map and ESTIA reflectometry tests: check whether a small synthetic input is enough, or whether they can be marked slow/integration and kept out of the PR-blocking jobs.

A cache is only worth adding for what remains.

Cache cost and limits (if still needed)

• GitHub gives each repo 10 GB of Actions cache. Entries unused for 7 days are evicted; the oldest are evicted first when the repo exceeds 10 GB.
• The repo is already at 12.2 GB over 124 entries: setup-python 6.1 GB (18 entries) and docker buildkit-blob 6.0 GB (81 entries). A new entry competes with these for space and can evict the pip cache.
• Entries written on a PR branch are not visible to other PRs. Only main entries are shared, so the cache must be saved on main runs (including the nightly) for it to cover an outage.
• actions/cache does not overwrite an existing key. With a broad restore-keys fallback and a stable key, new data files are never saved and are re-downloaded every run. Key on a hash of requirements/*.txt so each dependency bump saves a fresh entry.
• Size: the data directory on a developer machine is 7.8 GB (loki 2.7 GB, bifrost 1.4 GB, beer and estia 1.1 GB each), but this covers every instrument ever used. The CI subset is unmeasured; measure it with du ~/.cache/ess ~/.cache/esslivedata at the end of a test job before choosing keys. ~/.cache/esslivedata is about 27 MB and can share the entry.
• A cache hides an outage only while it is warm. After a key change during an outage the run still fails.
• Pruning the docker buildkit-blob entries (mode=max) would free more space than this change adds.