Improve developer productivity with CI enabled workflows

[aidanheerdegen]

Spack deployment repositories, e.g. ACCESS-OM2, ACCESS-OM3, ACCESS-ESM1.5, serve a very important role in defining, building and depoying models, but they do add an extra hurdle for developers when testing their model component development in a pre-release environment.

This hurdle can be lowered by providing some tooling to make common workflows easier.

Single model component workflow

A common workflow would be a developer working on a single component of a multicomponent model. Typically this work would be on a feature branch of the modelcomponent repo. Developers will usually compile locally, but regularly push work to the access-nri/modelcomponent repo on GitHub.

In order to share their work the developer needs to create a PR against the access-nri/model deployment repo that references their feature branch on the access-nri/modelcomponent repo.

This would require creating a feature branch on the access-nri/model repo with a change like so in spack.yaml

spack:
  specs:
    - [email protected]
  packages:
    modelcomponent:
      require:
        - '@git.feature'
  ...

and then creating a PR for feature branch. Let's call this feature-PR. This then creates a pre-release deployment for feature-PR.

Now some time later when the developer pushes changes to their feature branch on the access-nri/modelcomponent repo it has no effect on feature-PR. There needs to be a change to the spack.yaml file pushed to the feature branch of access-nri/model to trigger CI to deploy a new pre-release PR.

Proposal

1. Create a CI comment command in build-cd that will update the spack.yaml automatically, and so trigger a pre-release build, say !deploy
2. Command could do an empty commit but better would be to get the most recent git hash from the the modified modelcomponent branch and add that as a comment in the spack.yaml (props to @CodeGat for the idea). This would then add some useful information to the commit. Would also have the useful side-effect that there would be no commit, and therefore no build, if there isn't a new commit in the access-nri/modelcomponent feature branch.

This would require some inspection of spack.yaml to determine which modelcomponent is being updated.

Or .. we could do it for every package that specifies a @git.* version as a general approach in the CI. It would make it very easy to see what commits a tag referred to and this command would then just run the same action and only commit if there had been a change. Using this approach would mean this could also be generalised to a multiple model component workflow with no change ...

Final workflow

1. Create feature branch and push to access-nri/modelcomponent
2. Create feature branch on access-nri/model, update spack.yaml to reference [email protected]
3. Create feature-PR pull request from feature branch on access-nri/model

Development workflow looks something like:

while develop feature:
    while develop locally:
        make code changes
		compile && commit 
		if ready to share:
			push to remote branch
			if want to deploy
				add "!deploy" comment on feature-PR

Developers can push changes as often as they like to the feature branch on access-nri/modelcomponent but have option to deploy only when they think it is necessary.

After initial set-up of the feature branch on access-nri/model the only additional step to deploy updated code is to add !deploy comment to the PR. This is possible from the command line using gh:

gh pr comment feature --repo access-nri/model --body '!deploy'

[aidanheerdegen]

Or .. we could do it for every package that specifies a @git.* version as a general approach in the CI. It would make it very easy to see what commits a tag referred to and this command would then just run the same action and only commit if there had been a change. Using this approach would mean this could also be generalised to a multiple model component workflow with no change ...

Actually I'm not sure what I was thinking here, because no other CI/CD commits changes to spack.yaml ... does it?

[CodeGat]

1. Create a CI comment command in build-cd that will update the spack.yaml automatically, and so trigger a pre-release build, say !deploy

Would this be commented on the model PR, or the model-component PR?

no other CI/CD commits changes to spack.yaml ... does it?

No

[aidanheerdegen]

1. Create a CI comment command in build-cd that will update the spack.yaml automatically, and so trigger a pre-release build, say !deploy

Would this be commented on the model PR, or the model-component PR?

model PR. It has a direct connection with the model-component PR and any commit in that PR will trigger a new build. That isn't the case for the model-component PR. I guess there isn't anything stopping the CI from adding a comment to the model-component PR saying that a new build has been deployed from the model PR.

no other CI/CD commits changes to spack.yaml ... does it?

No

Right, so there goes that idea.