Deploy to a `spack` specified by `.spack` in `config/versions.json`

[CodeGat]

Instead of having to create vars for each full spack, spack-packages and spack-config path on the deployment target, have a single vars.SPACK_INSTALLS_ROOT_LOCATION and piecewise construct the above paths using the .spack version field in config/versions.json. This also means that we don't have to update the above vars when we want to deploy to a different version of spack, and users will have the freedom to pick a deployed version of spack to pre/release to.

For example, for spack-packages version, the full path change from a vars.SPACK_PACKAGES_LOCATION to vars.SPACK_INSTALLS_ROOT_LOCATION/<spack version>/spack-packages.

• [x] Will need to update vars.SPACK_INSTALLS_ROOT_LOCATION in our existing Gadi [Prerelease] in ACCESS-OM2, ACCESS-OM2-BGC, ACCESS-OM3, ACCESS-ESM1.5 and then remove vars.SPACK_*_LOCATION when it's merged.

In this PR:

• deploy-2-start.yml: Deploy paths created in step using .spack version

Closes #93

[aidanheerdegen]

In case I forget again in the future, the vars. namespace is populated in the Settings tab for each repo, e.g. in https://github.com/ACCESS-NRI/ACCESS-OM2/settings/variables/actions

[CodeGat]

I know it's not strictly speaking part of this PR, but I'm a bit concerned vars.SPACK_YAML_LOCATION is set to be the same for all models. So they could overwrite that path. Why not append a model specific subdirectory to vars.SPACK_YAML_LOCATION, or also generate that automatically and put it somewhere that is visible to other users?

@aidanheerdegen that's a fair concern. It's more of a temporary staging area for the spack.yaml before we run spack env create <env> ${{ vars.SPACK_YAML_LOCATION }}, where it is then copied into $SPACK_ROOT/var/spack/environments/<env>/spack.yaml. I'll add a commit here that disambiguates them - maybe so it is like <model>.spack.yaml (for example, access-om2.spack.yaml). It then has no chance of being overwritten during deployments of multiple models, since we have a concurrency directive that means only one model can be deployed at any one time.

See https://github.com/ACCESS-NRI/build-cd/pull/96/commits/9d5f0e8bf4bb22ee7784f7e68821a82464feb1a1