build-ci v3: Update Infra For spack v1

[CodeGat]

References issue ACCESS-NRI/build-ci#231 and PR ACCESS-NRI/build-ci#253
References project Spack `0.22` to `1.0` Migration

Important

This PR is a major update to the infrastructure. See below for the prerequisites for this repository to be able to merge this PR.

Important

This major version change marks the end of major infrastructure updates for CI using spack < 1.0. They will still get bug fixes and non-breaking features if required.
If you want to deploy to instances of spack < 1.0, you must use build-ci v2.
If you want to deploy to instances of spack >= 1.0, you must use build-ci v3.

Background

We are looking to transition build-ci to v3! This is due to a migration to spack v1.X, from v0.X, which offers many bug fixes, features, and optimisations.

One of these changes is the splitting of spacks core codebase from the builtin spack-packages repository, which means that we have another lever to tweak for our builds: the version of spack, spack-config, our spack-packages and the (new!) builtin spack-packages.

Since we want to leave open the possibility of forking the builtin spack-packages, we have also decided to rename ACCESS-NRI/spack-packages to ACCESS-NRI/access-spack-packages. See ACCESS-NRI/access-spack-packages#295 for more info.

Therefore this is a major version update, as there are the following changes to the inputs (and analogous changes to the workflow outputs):

• Deleted the optional spack-packages-ref input, which defaulted to main (in future, api-v1).
• Added the optional access-spack-packages-ref input, which defaults to the api-v2 branch.
• Added the optional builtin-spack-packages-ref input, which defaults to the main branch.

This means that:

• If you want to use container-image-version: :rocky-0.22-*, or spack-ref < releases/1.0, you must stay on v2 due to the input changes.
• If you want to use container-image-version: :rocky-1.*-*, or spack-ref >= releases/1.0, you must migrate to v3 due to the input changes.

It is possible to test across these versions of spack if required, via a mix of workflow versions. Ask @CodeGat if you need this functionality.

Features

The main new features include:

• Proper Spack v1 Support: Users now can tweak both the builtin spack-packages repository, as well as our own access-spack-packages repository. All of the bugfixes, features and optimisations added since 0.22 are available to us for future inclusion into build-ci.
• GitHub Hosted via ci.yml: A special extra feature for CABLE-LSM! We can now combine the self- and GitHub-hosted versions of the workflow into one file, so now one just needs to do inputs.run-self-hosted:false!

Prerequisites for Merging

• Update build-ci entrypoints to v3 (this PR!)
• Determine if a specific builtin-spack-packages-ref is required
• Determine if the added access-spack-packages-ref is appropriate
• Validate if maintainers want to move to spack v1 over spack v0.22

---

📚 Documentation preview 📚: https://cable--654.org.readthedocs.build/en/654/

[CodeGat]

Note: This will continue to run the v2 branch CI as v3 is at the head of v2 while the build-ci PR is being reviewed.

[SeanBryan51]

Hi @CodeGat, these changes look good to me! Happy to approve once you are ready on your end. Just a small nitpick regarding the commented out options

[CodeGat]

Note that we are seeing a similar error across packages using intel@2021.10.0 - see https://github.com/ACCESS-NRI/access-spack-packages/actions/runs/20066095596?pr=332
I'll park this until we have a resolution!

[CodeGat]

Ah, some new issues. GitHub-hosted runners only guarantee 14GB of free space, which is smaller than the new 2025.12.001 image we have (17GB). See https://github.com/CABLE-LSM/CABLE/actions/runs/20700259609/job/59421440822?pr=654#step:2:156

Will have to resolve this, first...