Release Procedure for OM3

[anton-seaice]

We should write a release procedure for ACCESS-OM3, encapsulating the related spack / build and configuration steps to produce a coherant / complete release.

I think this would cover:

• Tagging and versioning the build (i.e. this repo).
• Building through spack, and creating / moving to the final location if needed
• Copying the inputs to a release folder (i.e. with a version number)
• Updating all the configuration repositories for release (including updating config.yaml to turn on runlog, collate, metadata, reproducibility, post-processing etc and any other updates needed for versioning. Possibly also change run frequencies and turn off debug logging.)
• Testing

@micaeljtoliveira has suggested we could write this in the form of an issue template (I think it would in main of this repository).

[micaeljtoliveira]

Copying the inputs to a release folder (i.e. with a version number)

With the layout chosen in #115, this should not be necessary.

I think you also need to add the following at the end of the list:

• Tagging all configuration branches

[anton-seaice]

We might want a step to validate the provenance of inputs. i.e. have the inputs been generated using released versions of packages and their dependencies captured

[aidanheerdegen]

Ultimately ACCESS-OM3 will be released using the pipeline and tools the model release team have (and are) developing.

This provides an opportunity to relieve the OSI team of the burden of a good deal of this process, and avoid duplication of effort.

We have a PR to create a model definition environment (spack.yaml) for ACCESS-OM3, which will mean we can deploy ACCESS-OM3 using the CD workflows.

You can then use PRs to this repo to create pre-release versions of the model with whatever changes you want. There can be multiple PRs and each commit to a PR is a self-contained environment (and pre-release deployment) that remains until the PR is merged or closed.

There are also plans to create CI workflows to automatically update model configurations when new model releases are created

ACCESS-NRI/build-cd#62

[anton-seaice]

Thanks Aidan,

I think we should write this proc to capture what we currently do. And then update it as the process gets more automated.

The proc would then assist to describe what needs to be (or is) automated, and we would always need some manual checks which could also be in the doc.

[micaeljtoliveira]

@aidanheerdegen There's one thing that is currently not very clear. Are the OM3 developers supposed to tag a release in this repo or not? I would have assumed so, as that's the standard practice, but it seems that from your point of view the only "release" is the spack environment?

[aidanheerdegen]

I think we should write this proc to capture what we currently do. And then update it as the process gets more automated.

The proc would then assist to describe what needs to be (or is) automated, and we would always need some manual checks which could also be in the doc.

Sounds like a good plan.

[aidanheerdegen]

Are the OM3 developers supposed to tag a release in this repo or not? I would have assumed so, as that's the standard practice, but it seems that from your point of view the only "release" is the spack environment?

This repo can, and should, have tagged releases. This is what is used to define what is built and released by the workflow, e.g.

https://github.com/ACCESS-NRI/ACCESS-OM3/blob/60a163f0393ad532736a74397c238b4ffe8b379c/spack.yaml#L11

From my perspective the "release" that is the model release team's responsibility is a deployed release (or pre-release) that builds and installs the software through the GitHub action workflow.

[micaeljtoliveira]

@aidanheerdegen Thanks for clarifying!

It would probably be less confusing if we started talking about releases (tagging a new software version) and deployments (building and installing said software version). At least I'm often getting confused about this 😞

From the latest comments, it seems that, from the list of steps above, the ACCESS-OM3 developers would be directly responsible for the first one (tagging). The other steps would be mostly automated, but some human intervention would be required from the OM3 developers and/or the NRI Release team.

I think it would still be good to have an overarching issue created from a template to follow the overall progress. gitlab has some very good features to link issues and PRs in such a way. Does anyone has any experience in doing something similar in github?