Investigate spack_packages tagging utility

[CodeGat]

Background
This repository uses tags in order to both mark significant events in it's history (namely, when model(-component)s are updated) for devs; and for CI pipelines to effectively name dependency images (for example, appending the version of spack_packages that the dependency images is built on - [email protected] <- the end bit).

A simple date-based tag (eg. 2023.08.15) isn't enough to specify what exactly has changed. So we can add an optional message after the tag (git tag 2023.08.15 -m "libaccessom2 1.2.3, mom5 1.3.4, ...") to note the versions explicitly at this point in history.

There are some things to consider below.

Tasks
Investigate whether:

• tags should be automagically generated by the CI pipeline, based on what parts of spack_packages are updated.
  • Pros: Less dev overhead
  • Cons: More complex CI pipeline
• tags with messages should be a release instead - allows better formatting than just a single message
• we should split tagging across access-om2 and access-om3, allowing building models conditionally based on what has changed in spack_packages. Examples of both follow:

If we rebuild everything even when only one model changes...

* tag: 2023.08.16 (access-om2: 1.3, <other accessom2 deps>, access-om3: 1.34, <other accessom3 deps>)
|\
| * commit: some change to access-om2 that requires a version bump
|/
* tag: 2023.08.13 (access-om2: 1.2, <other accessom2 deps>, access-om3: 1.34, <other accessom3 deps>)

We will eventually get these two dependency images:

build-accessom2-...-2023.08.16 (same spack_packages version)
build-accessom3-...-2023.08.16 (same here too)
# and the old ones
build-accessom2-...-2023.08.13
build-accessom3-...-2023.08.13

Even if nothing has changed for access-om3.

If we break them down model lines:

* tag 2023.08.20 (access-om2: 1.3, <other accessom3 deps>)
|\
| * commit: access-om2 bump
|/
* tag 2023.08.19 (access-om3: 1.35, <other accessom3 deps>)
|\
| * commit: access-om3 bump
|/
* tag 2023.08.13 (access-om2: 1.2, <other accessom2 deps>, access-om3, <other accessom3 deps>)

We would eventually have the following dependency images:

build-accessom2-...-2023.08.20
build-accessom3-...-2023.08.19
# and the old ones
build-accessom2-...-2023.08.13
build-accessom3-...-2023.08.13

Both options have pros/cons. Thanks to @harshula and @aidanheerdegen for the conversations surrounding this issue.

[aidanheerdegen]

I don't have anything substantive to add at this point, but I was interested to see how your git diagram would render with mermaid ...

gitGraph
       commit tag: "2023.08.13"
       branch "access-om3-bump"
       commit
       checkout main
       merge access-om3-bump tag: "2023.08.19"
       branch "access-om2-bump"
       commit
       checkout main
       merge access-om2-bump tag: "2023.08.20"

Loading

[CodeGat]

Unassigning myself for now as I'm working on Nirin runner stuff