Trivial Changes to spack.yaml Require Rebuild of Some Packages

[CodeGat]

Currently, doing trivial modifications to the spack.yaml (seen most prominently in #5) require rebuilding parallelio, esmf and (therefore) access-om3-nuopc. This is a bit of a time sink since esmf can take upwards of 1/2 an hour.

See the following runs, in which nothing was changed relating to the above packages: https://github.com/ACCESS-NRI/ACCESS-OM3/actions/runs/10987685371/job/30502929361?pr=5#step:8:767, https://github.com/ACCESS-NRI/ACCESS-OM3/actions/runs/10985399681/job/30497188155#step:8:773.

Determine if the current spack.packages.*.require statements are not restrictive enough to prevent a rebuild - https://github.com/ACCESS-NRI/ACCESS-OM3/pull/5/files#diff-e8582e74fa156f4e5729a850e52b24f2fde2d815c2c9c360f88c4cf90db851abR10-R20

Or maybe it's another problem?

[harshula]

Double check if the Spack hash is the same or if it has changed.

[CodeGat]

parallelio, esmf, access-om3-nuopc do change between runs.

[anton-seaice]

Both esmf and access-om3-nuopc have dependencies on parallelio (e.g. https://github.com/spack/spack/blob/c118c7733b9e20f079bb19b84b8ad60cacd2a673/var/spack/repos/builtin/packages/esmf/package.py#L91), so i'd guess its related to parallelio or one of its deps

[CodeGat]

Another avenue is the spack gc garbage collection that happens on removal of old Prerelease environments as part of on.pull_request.types.closed, see https://github.com/ACCESS-NRI/ACCESS-OM2/actions/runs/11396341321/job/31710012054#step:6:18