Infra Update v8: spack v1 Support

[CodeGat]

References issue ACCESS-NRI/build-cd#313 and PR ACCESS-NRI/build-cd#326
References rollout issue ACCESS-NRI/build-cd#328
References project Spack `0.22` to `1.0` Migration

Important

This PR is a major update to the deployment 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 deployments to spack < 1.0.
If you want to deploy to instances of spack < 1.0, you must use build-cd < v8.
If you want to deploy to instances of spack >= 1.0, you must use build-cd >= v8.

Background

We are moving on up to spack v1! This update to spack contains many bug fixes, optimisations and new features that can be incorporated into build-cd.

This update also contains changes that make spack v0.X incompatible with this build-cd v8 update - the most prominent one being the splitting of spacks core codebase from it's builtin spack-packages repo. This means that for provenance, one to keep track of both builtin spack-packages and our own, renamed access-spack-packages. build-cd will centrally control the version of builtin spack-packages for a given instance, and config/versions.jsons spack-packages key is renamed to access-spack-packages.

As noted earlier, this major version of build-cd can only support spack v1, due to spack v1-specific commands in the infrastructure. If you still want to deploy to spack v0.X, you will need to change build-cd to v7, and update the config/versions.json file/spack.yaml.

Features

• Support for spack v1: We're moving to a new, non-beta version of spack! It contains bug fixes, features and optimisations over the old version.

Prerequisites for Merging

• Update build-cd entrypoints (this PR!)
• Update config/versions.json with new inputs (also this PR!)
• Validate compiler additions to the spack manifest (this PR, too!)
• Test and Verify Model built with spack v1

---

🚀 The latest prerelease access-issm/pr32-14 at 0eb7e09 is here: #32 (comment) 🚀

[github-actions]

🚀 Attempted to deploy access-issm Prerelease pr32-1 with commit 2bad7f8

🖥️ Gadi Deployment ❌

[github-actions]

🚀 Attempted to deploy access-issm Prerelease pr32-2 with commit bd331da

🖥️ Gadi Deployment ❌

[github-actions]

🚀 Attempted to deploy access-issm Prerelease pr32-3 with commit 1951b7d

🖥️ Gadi Deployment ❌

[harshula]

FYI, This PR is likely impacted by spack/spack-packages#3505

[github-actions]

🚀 Attempted to deploy access-issm Prerelease pr32-4 with commit fa86b1e

🖥️ Gadi Deployment ❌

[github-actions]

🚀 Attempted to deploy access-issm Prerelease pr32-5 with commit 78cc570

🖥️ Gadi Deployment ❌

[github-actions]

🚀 Attempted to deploy access-issm Prerelease pr32-8 with commit fc6fb2a

🖥️ Gadi Deployment ❌

[harshula]

PR ACCESS-NRI/access-spack-packages#395 should fix missing compiler errors.

[github-actions]

🚀 Attempted to deploy access-issm Prerelease pr32-9 with commit d7c0552

🖥️ Gadi Deployment ❌

[github-actions]

🚀 Attempted to deploy access-issm Prerelease pr32-10 with commit 71a5447

🖥️ Gadi Deployment ❌

[github-actions]

🚀 Attempted to deploy access-issm Prerelease pr32-11 with commit 2e65089

🖥️ Gadi Deployment ❌

[harshula]

Hi @CodeGat , It looks like the zip timestamp build failure is not transient in Spack v1.1.

[CodeGat]

I'm looking into a fix into the package definition now.

EDIT: See ACCESS-NRI/access-spack-packages#396

[github-actions]

🚀 Attempted to deploy access-issm Prerelease pr32-12 with commit b979f82

🖥️ Gadi Deployment ✔️

Usage Instructions

access-issm, defined in spack.yaml, will be deployed to Gadi as:

• 2025.11.0 as a Release (when merged).
• pr32-12 as a Prerelease (during this PR).

This Prerelease is accessible on Gadi using:

module use /g/data/vk83/prerelease/modules
module load access-issm/pr32-12

When using the above modules, the binaries shall be on your $PATH.

For advanced users, this Prerelease is also accessible on Gadi via /g/data/vk83/prerelease/apps/spack/1.1/spack in the access-issm-pr32-12 environment.
Due to inode-saving measures, one will have to manually untar the environment metadata before environment activation with tar -xf .spack-env .spack-env.tar. It will require one to have write privileges.

Configuration Information

This Prerelease is deployed using:

• access-nri/spack on branch 1.1
• spack/spack-packages version 383e969358c951abe17623696083e6f862c4488e
• access-nri/access-spack-packages version issm-timestamp-fix
• access-nri/spack-config version 2026.02.003

If the above was not what was expected, commit changes to config/versions.json in this PR, or propose changes to build-cds config/settings.json.

[CodeGat]

The above access-spack-packages fix seems to work. When it's reviewed/merged, I can remove this temp commit.

[github-actions]

🚀 Attempted to deploy access-issm Prerelease pr32-13 with commit a1861a5

🖥️ Gadi Deployment ✔️

Usage Instructions

access-issm, defined in spack.yaml, will be deployed to Gadi as:

• 2025.11.0 as a Release (when merged).
• pr32-13 as a Prerelease (during this PR).

This Prerelease is accessible on Gadi using:

module use /g/data/vk83/prerelease/modules
module load access-issm/pr32-13

When using the above modules, the binaries shall be on your $PATH.

For advanced users, this Prerelease is also accessible on Gadi via /g/data/vk83/prerelease/apps/spack/1.1/spack in the access-issm-pr32-13 environment.
Due to inode-saving measures, one will have to manually untar the environment metadata before environment activation with tar -xf .spack-env .spack-env.tar. It will require one to have write privileges.

Configuration Information

This Prerelease is deployed using:

• access-nri/spack on branch 1.1
• spack/spack-packages version 383e969358c951abe17623696083e6f862c4488e
• access-nri/access-spack-packages version 2026.03.001
• access-nri/spack-config version 2026.02.003

If the above was not what was expected, commit changes to config/versions.json in this PR, or propose changes to build-cds config/settings.json.

[CodeGat]

Fix was merged, and deployed successfully without error. I think we can consider this ready to merge, once it is ready for the ISM team.

[github-actions]

🚀 Attempted to deploy access-issm Prerelease pr32-14 with commit a1861a5

🖥️ Gadi Deployment ❌

[github-actions]

🚀 Attempted to deploy access-issm Prerelease pr32-14 with commit 0eb7e09

🖥️ Gadi Deployment ✔️

Usage Instructions

access-issm, defined in spack.yaml, will be deployed to Gadi as:

• 2025.11.0 as a Release (when merged).
• pr32-14 as a Prerelease (during this PR).

This Prerelease is accessible on Gadi using:

module use /g/data/vk83/prerelease/modules
module load access-issm/pr32-14

When using the above modules, the binaries shall be on your $PATH.

For advanced users, this Prerelease is also accessible on Gadi via /g/data/vk83/prerelease/apps/spack/1.1/spack in the access-issm-pr32-14 environment.
Due to inode-saving measures, one will have to manually untar the environment metadata before environment activation with tar -xf .spack-env .spack-env.tar. It will require one to have write privileges.

Configuration Information

This Prerelease is deployed using:

• access-nri/spack on branch 1.1
• spack/spack-packages version 383e969358c951abe17623696083e6f862c4488e
• access-nri/access-spack-packages version 2026.03.001
• access-nri/spack-config version 2026.02.003

If the above was not what was expected, commit changes to config/versions.json in this PR, or propose changes to build-cds config/settings.json.

[CodeGat]

One question for the audience - is it okay if I explicitly require netlib-scalapack rather than the virtual package scalapack?

[harshula]

One question for the audience - is it okay if I explicitly require netlib-scalapack rather than the virtual package scalapack?

That's actually what is done by:

    scalapack:
      require:
      - 'netlib-scalapack@2.2.0'

The issm SPR contains:

depends_on("scalapack")

Or are you asking whether this can be changed to depends_on("netlib-scalapack")?