Use explicit versions of access-generic-tracers and access-mocsy

[dougiesquire]

This is a non-answer-changing update to the 2025.07.000 release to use explicit versions of access-generic-tracers and access-mocsy in the spack.yaml.

Configurations need not be updated to use this release since it is effectively identical to 2025.07.000. The change is only made so that people can use the spack.yaml on the main branch of this repo with the latest version of spack-packages.

---

🚀 The latest prerelease access-esm1p6/pr122-1 at 6ff899d is here: #122 (comment) 🚀

[github-actions]

🚀 Attempted to deploy access-esm1p6 Prerelease pr122-1 with commit 6ff899d

🖥️ Gadi Deployment ✔️

Usage Instructions

access-esm1.6, defined in ./spack.yaml, will be deployed to Gadi as:

• 2025.07.001 as a Release (when merged).
• pr122-1 as a Prerelease (during this PR).

This Prerelease is accessible on Gadi using:

module use /g/data/vk83/prerelease/modules
module load access-esm1p6/pr122-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/0.22/spack in the access-esm1p6-pr122-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 0.22
• access-nri/spack-packages version 2025.08.000
• access-nri/spack-config version 2025.08.000

If the above was not what was expected, commit changes to config/versions.json in this PR.

[dougiesquire]

If we don't want to actually deploy this, I could add [skip-ci] to the commit message

[dougiesquire]

If we don't want to actually deploy this, I could add [skip-ci] to the commit message

Thinking about this more, probably this is a good idea

[aidanheerdegen]

Thinking about this more, probably this is a good idea

You don't want to do a quick check that it doesn't break repro?

[dougiesquire]

You don't want to do a quick check that it doesn't break repro?

Sure I can (and will), but have you seen the change?

[anton-seaice]

I understand this is convenient, but it also kind of convoluted to push [skip CI] changes to main when making non critical updates to a deployment. If we had a better way of doing it that would be good ! (main and release branches ?, trigger deployments manually rather than a PR?)

[dougiesquire]

You don't want to do a quick check that it doesn't break repro?

I confirmed that this does not change answers here

I understand this is convenient, but it also kind of convoluted to push [skip CI] changes to main when making non critical updates to a deployment. If we had a better way of doing it that would be good ! (main and release branches ?, trigger deployments manually rather than a PR?)

@anton-seaice, could you open an issue about this? Are you okay to approve?

[anton-seaice]

Looks good - repro test shows no change :)