Prerelease: Unique Modulefiles

[CodeGat]

An oversight exists where prereleased models would have the same modulefile name as the soon-to-be-released one. For example, access-om3/2024.02.1. This would not change between commits in the PR, which would mean a bunch of deployed prereleases would share the same module name above, with only the first being pointed to.

This PR adds a step into the deployment workflow in which we modify the version of the root SBD that the model is based on, giving it a unique <model>/pr<number>-<commit> style, similar to the spack env name. For example, access-om3/pr12-2.

We've had to propagate the root-sbd input from the ci step all the way through the deployment workflow, as the yq that overwrites the version may have a different name than the actual name of the model. For example, we used to have access-om3-virtual being the root SBD of the access-om3 model, before it was changed.

[aidanheerdegen]

If we added the modules to a different module path (in pre-release) this wouldn't be necessary. Just sayin'

[CodeGat]

How so? What would that look like?
Would that solve the issue of deploying multiple spack.yamls with the same modulefile projections, like {name}/2024.03.0?

[aidanheerdegen]

How so? What would that look like?

mkdir /g/data/vk83/prerelease/modules

I feel like this is all dancing around similar areas as #59

Pre-release currently uses spack, spack-config and spack-packages from the release directory. If there was an entire replicated directory structure under prerelease then there would be a modules directory and all associated config etc.

Would that solve the issue of deploying multiple spack.yamls with the same modulefile projections, like {name}/2024.03.0?

Uh, no it wouldn't. We could either have a modulefile projection that just points to the most recent prerelease, or we'd have to make these changes anyway. As we're moving to using module load version within payu as the preferred way of changing model versions it makes sense to have all pre-release deployments available as modules (see ACCESS-NRI/model-config-tests#10).

So (kinda) ignore my comment above.

[aidanheerdegen]

LGTM