[CodeGat]

Testing out ACCESS-NRI/build-cd#155 via a env-level spack.modules.default.roots.tcl: $env/modules.

This config would be pushed down to the spack-config level if it passes, but this should be a good test of the modules being loadable on install, and removed when the PR is closed. In the proper implementation, we would need to update the module magic to search for $spack/../environments/*/modules instead, but for now I'll load them manually.

---

🚀 The latest prerelease access-om2/pr163-2 at 16f8f0f is here: #163 (comment) 🚀

[github-actions]

🚀 Attempted to deploy access-om2 Prerelease pr163-1 with commit 9ac0b20

🖥️ Gadi Deployment ✔️

Usage Instructions

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

• 2026.08.000 as a Release (when merged).
• pr163-1 as a Prerelease (during this PR).

This Prerelease is accessible on Gadi using:

module use /g/data/vk83/prerelease/modules
module load access-om2/pr163-1

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-om2-pr163-1 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
• ACCESS-NRI/upstream-spack-packages version access/v1.1
• access-nri/access-spack-packages version 2026.08.011
• access-nri/spack-config version 2026.08.001

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

[CodeGat]

As it stands now, 9ac0b20 loads as a module only if we add the architecture to the module use. I think this is done by @aidanheerdegen s module magic automatically:

$ module use /g/data/vk83/prerelease/apps/spack/1.1/environments/access-om2-pr163-1/modules/linux-rocky8-x86_64_v4/
$ module load access-om2/pr163-1
Loading access-om2/pr163-1
  Loading requirement: access-om2/dependencies/pr163-1/oasis3-mct/2025.03.001-pzsb3kg access-om2/dependencies/pr163-1/libaccessom2/2026.08.000-gbeuq7x
    access-om2/dependencies/pr163-1/cice5/2026.07.000-vspuwkw access-om2/dependencies/pr163-1/mom5/2026.02.001-tpxmlif

But, it seems that spacks module.yaml offers a solution - the modules.default.arch_folder: false section is supposed to strip out that architecture folder. Not sure if that is what we want overall (modulefile clashes....? Doesn't seem likely) but I'll test it here. It might simplify Aidans module magic logic a bit if we can get spack to flatten the directory somewhat.

The structure of the modules is:

/g/data/vk83/prerelease/apps/spack/1.1/environments/access-om2-pr163-1/modules/
├── linux-rocky8-x86_64_v4
│   └── access-om2
│       ├── dependencies
│       │   └── pr163-1
│       │       ├── cice5
│       │       │   └── 2026.07.000-vspuwkw
│       │       ├── libaccessom2
│       │       │   └── 2026.08.000-gbeuq7x
│       │       ├── mom5
│       │       │   └── 2026.02.001-tpxmlif
│       │       └── oasis3-mct
│       │           └── 2025.03.001-pzsb3kg
│       └── pr163-1
└── module-index.yaml

[github-actions]

🚀 Attempted to deploy access-om2 Prerelease pr163-2 with commit 16f8f0f

🖥️ Gadi Deployment ✔️

Usage Instructions

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

• 2026.08.000 as a Release (when merged).
• pr163-2 as a Prerelease (during this PR).

This Prerelease is accessible on Gadi using:

module use /g/data/vk83/prerelease/modules
module load access-om2/pr163-2

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-om2-pr163-2 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
• ACCESS-NRI/upstream-spack-packages version access/v1.1
• access-nri/access-spack-packages version 2026.08.011
• access-nri/spack-config version 2026.08.001

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

[CodeGat]

Cool, the modules.default.arch_folder: false works in 16f8f0f:

$ module use /g/data/vk83/prerelease/apps/spack/1.1/environments/access-om2-pr163-2/modules/
$ module load access-om2/pr163-2
Loading access-om2/pr163-2
  Loading requirement: access-om2/dependencies/pr163-2/oasis3-mct/2025.03.001-pzsb3kg access-om2/dependencies/pr163-2/libaccessom2/2026.08.000-gbeuq7x
    access-om2/dependencies/pr163-2/cice5/2026.07.000-vspuwkw access-om2/dependencies/pr163-2/mom5/2026.02.001-tpxmlif

/g/data/vk83/prerelease/apps/spack/1.1/environments/access-om2-pr163-2/modules/
├── access-om2
│   ├── dependencies
│   │   └── pr163-2
│   │       ├── cice5
│   │       │   └── 2026.07.000-vspuwkw
│   │       ├── libaccessom2
│   │       │   └── 2026.08.000-gbeuq7x
│   │       ├── mom5
│   │       │   └── 2026.02.001-tpxmlif
│   │       └── oasis3-mct
│   │           └── 2025.03.001-pzsb3kg
│   └── pr163-2
└── module-index.yaml

Final thing to test...the cleanup!

[CodeGat]

The modules are now inaccessible after the PR clean up...looks good to me!!

$ module use /g/data/vk83/prerelease/apps/spack/1.1/environments/access-om2-pr163-1/modules
ERROR: Directory '/g/data/vk83/prerelease/apps/spack/1.1/environments/access-om2-pr163-1/modules' not found
$ module use /g/data/vk83/prerelease/apps/spack/1.1/environments/access-om2-pr163-2/modules
ERROR: Directory '/g/data/vk83/prerelease/apps/spack/1.1/environments/access-om2-pr163-2/modules' not found

[aidanheerdegen]

I think we definitely don't need to worry about module file clashes for pre-release. Given we're also bunging a short hash on the end I don't think we need to worry in general.