Infra Update `v4`: Support `spack.repos`, Add Tiered Common Configuration Via `spack.include`

[CodeGat]

References #318

Background

In a similar vein to ACCESS-NRI/build-cd#404, spack > 1.0 now supports things that we used to do in the infrastructure, in spack itself. This means that we can simplify our infrastruture by using spack-aware features, rather than rolling our own. In this PR, there are two:

Deprecating inputs.*-spack-packages-ref in favour of a manifests spack.repos section

We used to manually update the on-image access-spack-packages/builtin repos with the version given in inputs.*-spack-packages-ref. Rather than doing that, we opt for using a spack.repos section in a similar way to MDRs - see https://github.com/ACCESS-NRI/ACCESS-OM3/blob/1b4cf0afdd1fc7db232ceb266975a2b1b617cde0/spack.yaml#L108-L112

Note

If you didn't specify inputs.*-spack-packages-ref (like most people didn't), it will continue to just use the HEAD of access-spack-packages api-v2 branch, and the HEAD of upstream-spack-packages access-v1.1 branch (informed by spack-config). Nothing changes there!

Deprecating inputs.spack-manifest-data-path in favour of a manifests spack.include section

This is a bit of a bigger change, and looks to solve three issues:

• There is a lot of duplication in CRs .github/build-ci/data/standard.json - most of it is essentially the same intel_compiler_ver: 2021.10.0-style version specification.
• There is a lot of duplication in CRs manifests, as well - almost all of them have the same spack.packages.all.target section, compiler definitions, and spack.concretizer/spack.view sections that aren't really all that interesting.
• If we ever need to change a compiler version or package version across all manifests, we would need to update all manifests for all CRs!

Both of these can be solved by one of spacks own features - spack.include - which allows tiered, overridable configuration. We are looking to have one top-level set of configuration for very general, basic stuff that is copied across all manifests, that lives in access-spack-packages.

Optionally, for configuration that is shared between manifests in in a CR, we can also include that as well, too. It would look something like this, say for MOM6:

spack:
  include:
  # Very general, basic configuration copied across all manifests is defined centrally here, so it doesn't have to in this manifest
  - git: https://github.com/ACCESS-NRI/access-spack-packages
    branch: api-v2
    paths:
    # A manifest that includes c/cxx/fortran compiler requirements, concretizer args, etc.
    - .github/build-ci/includes/intel.spack.yaml
  # # Optionally, if there was configuration shared between manifests, one could include config from the CR, too:
  # - git: https://github.com/ACCESS-NRI/MOM6
  #   {{ ref_type }}: {{ ref }}
  #   paths:
  #   - .github/build-ci/includes/base.spack.yaml
  specs:
  - access-om3 ^MOM6@git.{{ ref }}
  # ... more of the usual, if you want to override the above includes!

The PR

• Update the workflow entrypoints, as usual!
• Remove any inputs.*-spack-packages-refs and transplant them into manifests spack.repos sections
• Remove any inputs.spack-manifest-data-path and replace that with spack.include entries, either from Add top-level spack.includes default access-spack-packages#484 or a CR-level manifest to include.

Testing

See below!