`git.BRANCH` References Are Not Picking Up Changes In Linked Repository

[CodeGat]

Similar to #2.

Background

Code changes to the underlying branch in a git.BRANCH reference aren't being picked up during a new install of a model. Even with a workaround that updated the underlying repositories the install still reused an existing package.

When building this in a separate instance manually, the code changes are picked up, and the model fails to build (which is expected, as there was an error in the code).

Workarounds

Currently, the only workaround seems to be using a git.TAG or git.COMMIT reference, rather than a git.BRANCH reference.

Implementation Plan

Copy the instance that is having an issue, and then:

• Investigate the spack solve of the access-esm1p6 package to figure out why it is reusing builds. Too difficult to parse the output, doesn't have anything to do with how it is deciding to pick the ref.
• Determine if removing the UM7 package and reinstalling successfully picks up the changes (which would mean that spack is preferring an already built artefact over a potential code change). Removing the package is not feasible as it is a dependency of other environments
• Determining if clearing the stage/buildcache is enough to get spack to pick up changes. Nope
• Other things as they come up...

[CodeGat]

Raise whether spack keeps track of the commit hash in a @git.branch reference. If it doesn't, then maybe it doesn't keep track of the state of the branch at all. Note that we couldn't find it when interrogating spack python

[CodeGat]

After chatting with a spack dev, this is potentially expected behavior, but it is behavior that they would like to change. This means that currently, @git.BRANCH references do NOT interrogate the state of the branch during concretization, and therefore they are not suitable for our use case.

We should use either a @git.TAG or @git.COMMIT reference from now on.

[CodeGat]

Linking spack#44319