Warm cache: verify looptools content before combining and cleaning

[oliviermattelaer]

Problem

The last cache warming combined everything and deleted the intermediate caches, but looptools was not complete.

looptools_cache has no verification step — unlike pythia8_cache and contur_cache, which both check their artifacts landed. ./bin/madgraph cmd exits 0 even when install collier / install ninja fails, so the job went green with a half-populated cache. heptools_cache then gated the combine only on needs.*.result == 'success', folded the incomplete content into heptools-$KEY, and deleted every sub-cache — destroying the only good copies.

Changes

heptools_cache — validate the content, not the job results

New Validate restored heptools content step inspects the actual restored files after the cache/restore steps and exports complete=true/false plus a missing= list. The three dangerous steps (delete-previous, save, cleanup) are now gated on steps.validate.outputs.complete == 'true'.

When something is missing: nothing is saved, no intermediate cache is deleted, and a final step writes a job summary naming the missing tool and fails the job (previously it went green while silently skipping the combine). Re-running just the failing job is then enough — the others cache-hit and the combine/cleanup completes.

The looptools half checks CutTools/lib/libcts.a, CutTools/lib/mpmodule.mod, IREGI/src/libiregi.a, ninja/lib/libninja.a and collier/libcollier.a — exactly the paths restore_heptools_looptools configures and that activate_dependence in madgraph/various/misc.py looks for.

looptools_cache — fail at the source

New Verify looptools landed in the cache step, mirroring the existing pythia8/contur ones. actions/cache skips its post-save when the job fails, so an incomplete looptools-<os> is never stored. It runs on the cache-hit path too, so an already stored bad cache is reported instead of being silently reused forever.

delete-cache — two fixes

• looptools-<os> was missing from the reset_heptools delete list, so an incomplete looptools cache could never be reset.
• if: inputs.reset_* == 'true' is always false: workflow_dispatch boolean inputs are booleans, and GitHub casts to number on a loose comparison (true → 1, 'true' → NaN). All four reset_* deletes were inert. Now testing the boolean itself.

restore_heptools — tighten the consumer-side check

Its validate cache content only tested -d .../ninja, which a failed install still leaves behind. Now checks libninja.a, libcollier.a, libcts.a and libiregi.a, so a bad combined cache falls back to the sub-caches instead of silently breaking the MadLoop link.

Testing

Both new shell blocks and the summary/heredoc step were extracted from the YAML and run locally against a fake HEPtools tree, in the complete case (exit 0, complete=true) and the incomplete case (correct per-tool warnings, de-duplicated missing list, exit 1). The workflow and action YAML both parse.

To recover the current state

Re-run Warm all caches via Run workflow with reset_heptools ticked — that now actually fires, and now also drops looptools-<os>.

🤖 Generated with Claude Code