Skip to content

ci: add spack lockfiles and drop dead setup-spack ref#548

Draft
dennisklein wants to merge 2 commits into
FairRootGroup:devfrom
dennisklein:ci-spack-lockfiles
Draft

ci: add spack lockfiles and drop dead setup-spack ref#548
dennisklein wants to merge 2 commits into
FairRootGroup:devfrom
dennisklein:ci-spack-lockfiles

Conversation

@dennisklein
Copy link
Copy Markdown
Member

Follow-up to #547.

  • add the concretized test/ci/locks/<env>-gcc<N>.lock files (generated on ubuntu-24.04 by buildcache run 26721959759) so CI installs from a fixed concretization instead of re-solving
  • drop the ref input from setup-spack@v3 in the setup-deps action and the update-index job: v3 renamed it to spack_ref, so it was silently ignored and emitted a warning each run

- generated on ubuntu-24.04 by buildcache run 26721959759
- one lock per (env, gcc): latest gcc 12/13/14/15 and boost187 gcc15
setup-spack@v3 renamed ref to spack_ref, so the old ref input was silently
ignored (and emitted a warning each run) while spack ran on its develop
default anyway.

- remove the dead ref input from the setup-deps action and the update-index job
@dennisklein dennisklein marked this pull request as draft June 1, 2026 20:30
@dennisklein
Copy link
Copy Markdown
Member Author

Holding as draft. CI investigation shows the committed lockfiles pin gcc as a host-path external (from spack compiler find), which doesn't transfer between runners — CI fails at CMake configure with CMAKE_CXX_COMPILER not set.

Root cause is broader: gcc is compiled from source (~58 min) on every buildcache run and never pushed (externals are excluded from buildcache push), so it's not cacheable and the lockfiles can't be portable. Investigating how to make the spack-built gcc a cacheable node before reworking this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant