Support spack.repos section in manifests

[CodeGat]

Closes #312
Related to ACCESS-NRI/build-cd#404

Important

This is a major-level change to the build-ci infrastructure, due to the removal of entrypoint workflow inputs inputs.*-spack-packages-ref. CRs will need to be updated to support this change if they specified those inputs.

Background

Similar to the above issue, now that we are using spack > 1.0, we can leverage Spack to handle cloning of git-based repositories, rather than having our own infra do it.

Unlike build-cd, which requires access-spack-packages to be defined (and hence a spack.repos section at all), build-ci is a bit more lax - if versions for access-spack-packages or builtin are not specified, we will take whatever is defined in spack-config (currently the branches api-v2 and access/v1.1 respectively). However, due to the magic of included configuration (see up the stack), the spack.repos section will always be defined.

If either are specified in the manifest, we will clone those repos under $env/package-repos (similar to build-cd) and they will be used instead.

The PR

• ci.yml: Remove inputs.*-spack-packages-ref
• Delete git-checkout-updated-ref, spack-checkout-updated-ref actions
• README.md: Remove references to inputs.*-spack-packages-ref

Updates required for CRs

• If inputs.*-spack-packages-ref was specified, one needs to add a spack.repos section similar to https://github.com/ACCESS-NRI/ACCESS-OM2/blob/d512fdfec7e95819ffbac66f6d7e653eebcc2c51/spack.yaml#L72-L76, depending on the repository.

Testing

Note

This testing is no longer relevant after f212a89, but it does show that it indeed clones the correct repos.

All were tested in ACCESS-NRI/MOM6#74, with each of the below cases being a particular manifest in ACCESS-NRI/MOM6@5d7f56c

MOM6, No spack.repos Section (oneapi_access-om3_asymm.spack.yaml.j2)

Success, updated the access-spack-packages and builtin - see https://github.com/ACCESS-NRI/MOM6/actions/runs/32921190984/job/98035370629?pr=74#step:20:1 and how the next two steps ran as expected.

MOM6, spack.repos Section Specifying accesss-spack-packages (oneapi_access-om3_symm.spack.yaml.j2)

Success, cloned the access-spack-packages repo and updated the builtin - see https://github.com/ACCESS-NRI/MOM6/actions/runs/32921190984/job/98035370566?pr=74#step:20:1.

MOM6, spack.repos Section Specifying builtin (oneapi_mom6_access3.spack.yaml.j2)

Success, cloned the builtin repo and updated the access-spack-packages - see https://github.com/ACCESS-NRI/MOM6/actions/runs/32921190984/job/98035370547?pr=74#step:20:1.

MOM6, spack.repos Section Specifying access-spack-packages, builtin (oneapi_mom6_solo.spack.yaml.j2)

Success, cloned both. See https://github.com/ACCESS-NRI/MOM6/actions/runs/32921190984/job/98035370557?pr=74#step:20:1, and how neither of the steps ran, as expected

[CodeGat]

This works, but there is a pretty significant slowdown when we update the builtin, due to the spack repo update followed by the manual fetch...see https://github.com/ACCESS-NRI/MOM6/actions/runs/32921190984/job/98035370629?pr=74#step:22:226 for example. Almost 1 1/2 minutes! I'll look into it

[CodeGat]

After chatting with @aidanheerdegen, I note that we can get around the long update times for the image by always having a spack.repos section - in the spack.include section, in access-spack-packages! In this way, we would not need to have steps to update the on-image repos at all, and potentially not have those repos included in the image at all.

[aidanheerdegen]

LGTM