mirror of
https://github.com/FairRootGroup/FairMQ.git
synced 2026-06-15 08:17:05 +00:00
bb5c0a998c
Reusing concretization between the weekly buildcache (fresh) and weekday CI (reuse) can drift if runner externals change, causing avoidable cache misses. - setup-deps installs from test/ci/locks/<env>-gcc<N>.lock when it exists, skipping concretization for byte-identical hashes; falls back to the spec yaml otherwise - buildcache exports each env's spack.lock as a downloadable artifact so the lockfiles can be regenerated on the ubuntu-24.04 runner and committed - document the manual regeneration flow in test/ci/locks/README.md
929 B
929 B
Committed spack lockfiles
setup-deps installs from <env>-gcc<N>.lock here when a matching file exists,
skipping concretization so the resolved hashes match the binaries the buildcache
pushed (guaranteed cache hits). When no lockfile is present it falls back to
concretizing from test/ci/spack-<env>.yaml.
Regenerating
Lockfiles pin host externals (glibc, system gcc), so they must be concretized on
the same runner image CI uses (ubuntu-24.04) — do not generate them on a
local machine.
- Run the
Spack Buildcacheworkflow (push todev/mastertouching the spack configs, orworkflow_dispatch). It concretizes fresh (fresh: 'true'), pushes binaries, and uploads each env'sspack.lockas alock-<env>-gcc<N>artifact. - Download the artifacts and commit them here as
<env>-gcc<N>.lock.
Regenerate whenever the specs in test/ci/spack-*.yaml change or the runner
image is bumped.