Tweaks to New Software Deployments in Building.md
#1029
Conversation
Corrected minor typos and clarified links in the documentation.
|
| ### New Software Deployments | ||
|
|
||
| When it is needed to update the model components to incorporate upstream updates to code, this triggers a new major release of the access-om3 executable. Incorporating upstream updates means that bug fixes and new features developed by the development communities are included. This is a release of the executable only and generally is not publicly announced. The new exectuables are then used in configurations. Note this is a distinct activity from configuration releases, which will use a specific access-om3 executable version and are publicly announced. The assumption is that most users will run or start from a release configuration, and often will not change the executable directly. | ||
| When it is needed to update the model components to incorporate upstream updates to code, this triggers a new major release of the access-om3 executable. Incorporating upstream updates means that bug fixes and new features developed by the development communities are included. This is a release of the executable only and generally is not publicly announced. The new exectuables are then used in configurations. Note this is a distinct activity from configuration releases, which will use a specific ACCESS-OM3 executable version and are publicly announced. The assumption is that most users will run or start from a release configuration, and often will not change the executable directly. |
There was a problem hiding this comment.
I think we normally capitalise when it's the build MDR?
Few tweaks from chat with @anton-seaice and @helenmacdonald
Updated the steps for testing components.
Minor tweaks to align with spack.yaml
Clarified definitions and updated links for component versions in the Building documentation.
adding the issue template
chrisb13
changed the title
New Software Deployments in Building.md
Updated steps for updating model component versions and dependencies in the documentation. Added detailed instructions for creating issues and PRs for testing new builds.
attempt at fixing render
trying to fix render
3rd time lucky?
Forth time syntax attempt
|
@dougiesquire, given we are shortly updating MOM6 to have mom6 solo, can you please update the list of built executables here: |
text tweak
| 1. **Setup a draft-PR** on a configuration. This allows for testing that the new build runs and has reproducability with previous builds. A draft-PR to [dev-MC_100km_jra_ryf](https://github.com/ACCESS-NRI/access-om3-configs/blob/e836a710b4324a6f942c8bd9855afb627c16e685/config/ci.json#L28-L29) can be a good choice as it runs [all](https://github.com/ACCESS-NRI/model-config-tests/?tab=readme-ov-file#selecting-tests-using-markers) (historical, determinism and determinism over restart) reproducability tests. If changing compilers, it may make sense to run these tests without compiler optisations on (e.g. -O0). | ||
| The versions can be changed in the access-om3 deployment repository by changing the [spack.yaml](https://github.com/ACCESS-NRI/ACCESS-OM3/blob/main/spack.yaml). Unless there is an interface change between depedencies, the old access-om3 model components should still build with the new dependencies. The following commands will create the needed pull request: | ||
|
|
||
| cd path/to/clone/of/access-om3-configs | ||
| gh issue create --title "Testing model upstream component and dependencies update: 2026.01.000" --body "Issue to discuss the testing of new model build 2026.01.000." --assignee "@me" --label "all-configurations" | ||
| git checkout dev-MC_100km_jra_ryf | ||
| git checkout -b 1032-model-buid-update-test | ||
| #edit `spack.yaml` | ||
| git push origin 1032-model-buid-update-test | ||
| gh pr create --title "Testing model build 2026.01.000 on " -B dev-MC_100km_jra_ryf --body "Closes #1032. PR to test new om3 build 2026.01.000." -d |
There was a problem hiding this comment.
This can now be done automatically from the prerelease MDR PR using the new !update configs workflow. Example here.
| @@ -87,10 +99,10 @@ The versions can be changed in the access-om3 deployment repository by changing | |||
|
|
|||
There was a problem hiding this comment.
Re
3. create a new branch with a temporary name (e.g. _rc-dev/2025.08_ or _rc-CICE6.6.1-x_)
we're missing a step between 5 and 6 (to seek review?) and then move to the permament branch name (e.g. (e.g. _rc-dev/2025.08_ or _rc-CICE6.6.1-x_) )
There was a problem hiding this comment.
Why is the temporary branch needed?
There was a problem hiding this comment.
So that you can push the branch to run build-CI and still be able to change after pushing
There was a problem hiding this comment.
change after pushing
Here you mean rewrite history?
There was a problem hiding this comment.
Yeah, or add a commit.
e.g. say there is a new upstream file that is missing from CMakeLists, it should be easier for a developer to fix that
(The other option is to change the instructions to tell everyone to always use spack develop when doing the upstream update process)
There was a problem hiding this comment.
Because we used branch protections with wildcards, as soon as CICE6.6.1-x is pushed you then need a PR to change it
There was a problem hiding this comment.
Hey @dougiesquire and @anton-seaice, I appreciate the feedback but this is still a draft.
There was a problem hiding this comment.
Oh - sorry - This an existing issue which we could clarify and this seems to be looking at the same part of the docs. Shall i capture it somewhere else?
There was a problem hiding this comment.
I'm happy to get feedback, I just meant I don't want people to waste their time giving a thorough review at this point. Pointers like the two above (from Dougie too) are great.
I think the related issue is this one, which you've already been commenting. :)
Corrected minor typos and clarified links in the documentation.