Add model build CI for CABLE offline

[SeanBryan51]

Making CABLE available as a spack package allows us to test the model compiles successfully inside a continuous integration (CI) environment which gets triggered automatically on a pull request. This change adds the model build CI workflow developed by the ACCESS-NRI release team to compile CABLE offline via spack (see build-ci for more details). This workflow compiles CABLE using the intel compiler. The CI for other compilers will follow after this pull request.

Fixes #202

---

📚 Documentation preview 📚: https://cable--223.org.readthedocs.build/en/223/

[ccarouge]

Looking at 'model-1-build.yml', I have some questions. I have no idea yet if I can approve because all of the following will come later or if any of my questions are a deal breaker.

The way we get the version implies tags can only be used for versioning on the main branch. Correct?

Currently, this will only compile with ifort. Could this be made clear in the description of the PR. And make clear development of the CI for other compilers will follow. How will the CI work if a model wants to run CI using 3 different compilers and another model wants only to use 2 compilers (potentially different compilers from the other 3)?

This comment might be more for 'build-ci' itself than the current CI here, but how are we going to deal with model components that are part of different models? For example, MOM5 is part of ACCESS-OM2 and ACCESS-CM2. For the moment, I don't think it will impact CABLE but it could in the future.

Will the CI support different MPI implementations (OpenMPI and IntelMPI) ?

[SeanBryan51]

@ccarouge I will direct questions around model-1-build.yml to @CodeGat as he probably understands the implementation the best. I've made an issue ACCESS-NRI/build-ci#151 which describes additional functionality that would be useful for us and should cover most of your points.

It might take some time to implement the new functionality. Should we use the build-ci action as is for now?

We should also probably pin the action with a commit instead of main so that the CI in CABLE is unaffected by changes in build-ci. Will do this now.

[CodeGat]

Hi @ccarouge :) yes, please let me know of any functionality that you require, and I can work on it when possible. Currently we only use it for compilation testing in ACCESS-OM2/3 but it would be great to hear from model developers regarding their workflows so I can either add the needed functionality to build-ci (if it is sufficiently generic) or help out adding model-specific functionality to the workflow here.
Regarding the compiler stuff: currently we run the model on all compilers defined in build-cis config/compilers.json. I've heard from Sean as well that you might want to selectively build on certain compilers rather than all of them. I've had thoughts on doing this as well - adding an issue to build-ci would be great.

Tagging @aidanheerdegen as well so it's on his radar.

@SeanBryan51 yes, it is good practice to pin workflow versions for external workflows. Do note that you will have to update the workflow here whenever there is an update relevant to you (rather than just having the latest).

[ccarouge]

It's good to go