-
Notifications
You must be signed in to change notification settings - Fork 1
Home
This is the ACCESS-NRI fork of the canonical MOM6 Ocean Model "mom-ocean".
This workflow has been developed to enable ACCESS-NRI to be a MOM6 node whilst having flexibility to have releases that differ from the Mom-ocean repository. The aspiration is to stay as close to the MOM-ocean upstream as possible, contributing to development and always having a common parent with mom-ocean.
- Acceptance of PRs on MOM-OCEAN takes time and we want to be able to add commits to our local configurations whilst we are waiting for feedback;
- MOM-OCEAN is updated whilst we are developing a new feature which creates conflicts;
- MOM-OCEAN doesn’t accept part of our pull request and we wish to retain some parts for ACCESS-NRI releases;
- Want to avoid re-writing history on release code.
There are four kind of repositories/branches:
- mom-ocean main branch. Upstream canonical MOM6 repository. Constraint: History must be “clean” (no re-writing), needs to be relatable to one of our branches such that we can do edits on it.
- dev/access. The default
dev/accessbranch in this fork tracks themainbranch of canonical MOM6 repository. Changes are accumulated indev/accessprior to being proposed upstream ACCESS-NRI fork of mom-ocean main that is merged into from specialist dev forks when development work is done. History will be re-written at times on this branch so code should not be released on it. - dev-access-candidate-YYYYMMDD. ACCESS-NRI development branch that points to commits in “dev/access” to facilitate development work of a specific feature.
- rel/nn.p. ACCESS-NRI branch that enables Australian releases of: i) mom-ocean rejected code and ii) allows work to progress whilst waiting for PR approval. Release branches must have a common parent on mom-ocean. nn is the major release and p is a “point” release, nn starts at 0 and p starts at 1.
The process for proposing changes is as follows:
- Open an issue describing the need and context for your changes.
- Sync the
dev/accessbranch withmom-ocean/MOM6:main. If there are no conflicts, this can be done using the "Sync fork" button from the Github web UI. If there are conflicts, they will need to be resolved at the command line - see the Github docs on syncing a fork. - Checkout a feature branch
dev-access-candidate-YYYYMMDDfromdev/accessand make your changes. - Submit a PR to merge your feature branch into
dev/access.
The maintainers of this fork will periodically submit PRs to mom-ocean/MOM6:main to merge the accumulated changes in dev/access.
Rejected changes cannot be included in dev/access since it is important that dev/access shares a common history with upstream and other MOM6 development centres. This means that in the case of rejected changes:
- those changes will need to be disregarded, released on a release branch or moved to a new dev branch.
- the
dev/accessbranch will need to be reset to upstream.
Here's some example with Git DAGs. MOM-Ocean has say 3 commits:
%%{init: { 'logLevel': 'debug', 'theme': 'base', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'Mom-Ocean'}} }%%
gitGraph
branch dev/access
checkout Mom-Ocean
commit id:"A"
commit id:"B"
commit id:"C"
Sync the dev/access branch with mom-ocean/MOM6:main. Create a dev-access branch, e.g. dev-access-candidate-20240901, create changes and then merge back into dev/access
%%{init: { 'logLevel': 'debug', 'theme': 'base', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'dev/access'}} }%%
gitGraph
checkout dev/access
commit id:"A"
commit id:"B"
commit id:"C"
branch dev-access-candidate-20240901
checkout dev-access-candidate-20240901
commit id: "D"
commit id: "E"
checkout dev/access
merge dev-access-candidate-20240901
This may occur with multiple development branches, e.g.
%%{init: { 'logLevel': 'debug', 'theme': 'base', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'mom-ocean'}} }%%
gitGraph
checkout mom-ocean
commit id:"A"
commit id:"B"
commit id:"C"
branch dev/access
checkout dev/access
branch dev-access-candidate-20240901
branch dev-access-candidate-20241020
checkout dev-access-candidate-20241020
commit id: "D"
commit id: "E"
checkout dev/access
merge dev-access-candidate-20241020
checkout dev-access-candidate-20240901
commit id: "F"
commit id: "G"
checkout dev/access
merge dev-access-candidate-20240901
In the above example, what remains is to put a PR to put new features upstream, if all changes are accepted then:
%%{init: { 'logLevel': 'debug', 'theme': 'base', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'mom-ocean'}} }%%
gitGraph
checkout mom-ocean
commit id:"A"
commit id:"B"
commit id:"C"
branch dev/access
checkout dev/access
branch dev-access-candidate-20240901
branch dev-access-candidate-20241020
checkout dev-access-candidate-20241020
commit id: "D"
commit id: "E"
checkout dev/access
merge dev-access-candidate-20241020
checkout dev-access-candidate-20240901
commit id: "F"
commit id: "G"
checkout dev/access
merge dev-access-candidate-20240901
checkout mom-ocean
merge dev/access id:"H"
In the situation where some of the changes are rejected from the PR, if needed they can go back on a new dev branch (commit "I" below). Note that releases must be on their own branch and must have a common parent with Mom-Ocean:
%%{init: { 'logLevel': 'debug', 'theme': 'base', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'mom-ocean'}} }%%
gitGraph
checkout mom-ocean
commit id:"A"
commit id:"B"
commit id:"C"
branch dev/access
checkout dev/access
branch dev-access-candidate-20240901
branch dev-access-candidate-20241020
checkout dev-access-candidate-20241020
commit id: "D"
commit id: "E"
checkout dev/access
merge dev-access-candidate-20241020
checkout dev-access-candidate-20240901
commit id: "F"
commit id: "G"
checkout dev/access
merge dev-access-candidate-20240901
branch rel/0.n
checkout rel/0.n
commit id: "v0.1" tag: "v0.1"
checkout mom-ocean
merge dev/access id:"H"
branch dev-access-candidate-20241120
checkout dev-access-candidate-20241120
commit id: "I"
branch rel/1.n
commit id: "v1.1" tag: "v1.1"
commit id: "v1.2" tag: "v1.2"
checkout dev-access-candidate-20241120
commit id: "J"
As Mom-ocean receives updates from elsewhere, they will eventually be pulled into dev/access and the cycle can begin again:
dev/access
%%{init: { 'logLevel': 'debug', 'theme': 'base', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'mom-ocean'}} }%%
gitGraph
checkout mom-ocean
commit id:"A"
commit id:"B"
commit id:"C"
branch dev/access
checkout dev/access
branch dev-access-candidate-20240901
branch dev-access-candidate-20241020
checkout dev-access-candidate-20241020
commit id: "D"
commit id: "E"
checkout dev/access
merge dev-access-candidate-20241020
checkout dev-access-candidate-20240901
commit id: "F"
commit id: "G"
checkout dev/access
merge dev-access-candidate-20240901
branch rel/0.n
checkout rel/0.n
commit id: "v0.1" tag: "v0.1"
checkout mom-ocean
merge dev/access id:"H"
branch dev-access-candidate-20241120
checkout dev-access-candidate-20241120
commit id: "I"
branch rel/1.n
commit id: "v1.1" tag: "v1.1"
commit id: "v1.2" tag: "v1.2"
checkout dev-access-candidate-20241120
commit id: "J"
checkout mom-ocean
commit id: "K"
commit id: "L"
checkout dev/access
merge mom-ocean
Caveat, PRs to upstream are possibly submitted from "PR candidate" branches named PRcandidate-YYYYMMDD so that dev/access can continue during the review process (which can be slow).
New temporary branches should be created for testing PRs submitted to mom-ocean/MOM6:main from other centres.
For example, to create a branch to test this PR:
git remote add ncar [email protected]:NCAR/MOM6.git
git fetch ncar
git checkout dev/ncar-candidate-240319
git push origin dev/ncar-candidate-240319Test branches should be deleted once the PR is closed.