Save OPAM environments of dependency changes and bound the CI caches
Why
A pull request that changed the opam files rebuilt every OPAM environment on each push (531 s on Linux x64 to 953 s on Windows), since only pushes to master save caches. The caches exceeded GitHub's 10 GB, so live ones were evicted: the coverage build state, keyed on a hash of compiler/**, saved a new 266 MB entry on nearly every master push, earlier generations stayed until GitHub's 7-day eviction, and the compiler build states grew with dune's shared cache.
When an OPAM environment misses, a pull request that changes *.opam saves the one it built, in the cache scope of its merge ref, so its later pushes restore it. Each save deletes the earlier environments with the same key prefix on the same ref, and a new workflow deletes a closed pull request's caches. The coverage build state is gone, the compiler build states keep only _build, and the Linux system packages are installed with apt instead of unpacked from a cached tarball that dpkg didn't know about, so opam took them for missing.
Review
- Why not restore the environment of earlier dependencies and update it? The result would depend on what that environment held: pins, repository state, installed packages, depext status, global options. Environments are still only restored on an exact key, so each is the one a fresh build of its opam files produced.
- Why do only pull requests that change the opam files save? Any other pull request would store a copy of master's environments, 3.3 GB each.
- Was it tested? On this pull request: a temporary opam change built and saved all six environments, the next push restored them in 9-39 s, a second change replaced them, and reverting it restored master's again.