Suggestions for additional functionality (CABLE centric)

[SeanBryan51]

After giving the build-ci a test drive (see CABLE-LSM/CABLE#223), @ccarouge and I have some suggestions that would improve our experience:

• As a user of the action, I want to specify the spack spec being used when compiling the model so that I can see the versions of dependencies, variants (compile options), etc.
  • An approach could be if the action provides an install of spack along with all the access-nri spack-packages and it is left to the user of the action to invoke the relevant spack commands?
• As a user of the action, I want to compile the model with multiple spack specs of my choosing so that supported build configurations can be tested. E.g. different compilers, different variants (in particular release and debug build types), different MPI implementations, different versions of dependencies, etc.
  • It looks like the spec-matrices feature for spack.yaml files could be useful for this sort of thing?
• As a user of the action, I want to use the action by adding solely the uses: access-nri/build-ci/.github/workflows/... in my GithubActions workflow file so that there is minimal overhead in setting up the action.
  • Currently to use the action we have to commit an entry to config/models.json in the build-ci repo.

[CodeGat]

Thanks for that @SeanBryan51 :) It's on my radar

[CodeGat]

Some questions and comments for @SeanBryan51 and @ccarouge :

• The spack.yaml(s) will have to be stored in the CABLE repository - is this okay?
• How would you like the above functionality - on.pull_request or on.workflow_dispatch (manually invoked)? Both have distinct advantages and disadvantages.
  • For on.pull_request: Runs automatically, can block merging of pull requests, but you cannot configure aspects of the CI run without storing that configuration data in the repository itself, and making it part of your commit history. For example, choosing which spack.yaml you want run would mean modifying the spack.yaml in the PR.
  • For on.workflow_dispatch: Doesn't run automatically, can't block PRs, can be run whenever, configuration details can be modified in the inputs fields. For example, you could pick something equivalent to 'run the following spack.yamls from the given branch/commit/etc'.

[SeanBryan51]

The spack.yaml(s) will have to be stored in the CABLE repository - is this okay?

Yep this is all good.

How would you like the above functionality - on.pull_request or on.workflow_dispatch (manually invoked)?

on.pull_request so that we can block merging of PR's in case a build fails. I don't mind having the configuration data being part of the commit history in the CABLE repository.

[CodeGat]

Going to get onto this issue when I have a spare couple minutes. Thanks for your patience.

[ccarouge]

No pressure @CodeGat . These are useful additions to the CI for us but they aren't major priorities so far. We should aim to have this done before the release of CABLE4-beta (first half of 2025).

[CodeGat]

It'll definitely be done before then! 😁