New CI test to build iturbo

[mnlevy1981]

Description

Build the MOM6 executable with both TIM and FMS when MOM6 is the dev/turbo-debug branch (instrumented TURBO, or iturbo) rather than the default dev/turbo branch

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Code maintenance (refactoring, optimization, etc.)
• CI/CD changes

Related Issues

We didn't create an issue, but when @johnmauff and I were working on TURBO-ESM/MOM6#18 and #224 we realized that the dev/turbo-debug branch won't build in turbo-stack until the TIM submodule is updated to bring in some new commits. That could have been caught by the CI if we were trying to build this branch of MOM6.

Changes Made

I duplicated build-tests.yaml and added a step to checkout dev/turbo-debug.

Testing

Test Environment

• Tested on derecho
• Tested locally
• Other: this is a CI test, and I expect the new test to fail on github because we need to update TIM

Test Cases

• All existing tests pass
• New tests added and pass
• New tests added and fail (until we update TIM)
• Manual testing performed
• Examples run successfully

Performance Impact

• No performance impact expected
• Performance improvement
• Potential performance impact (explain below)

Documentation

• Code comments updated
• README updated
• User documentation updated
• Developer documentation updated
• No documentation changes needed

Checklist

• My code follows the project's coding standards
• I have performed a self-review of my own code
• My changes generate no new warnings or errors
• Any dependent changes have been merged and published

[mnlevy1981]

I could see an argument for only testing iturbo with TIM (dropping FMS2 tests), but I think it's nice to show that we aren't accidentally trying to call TIM subroutines through the FMS2 infrastructure layer

[johnmauff]

@mnlevy1981 I have created a handful of unit tests that test the scaffolding functions that only exist in the iturbo branch. Do we also create an iturbo branch in turbo-stack that uses the proper version of MOM6?

[mnlevy1981]

@mnlevy1981 I have created a handful of unit tests that test the scaffolding functions that only exist in the iturbo branch. Do we also create an iturbo branch in turbo-stack that uses the proper version of MOM6?

I think it makes more sense to create a workflow that checks out iturbo and then runs the unit tests, much like I did for the "build the model" step; I can add that to this PR.

I also want to figure out why my new workflow didn't run on this branch... @mwaxmonsky, @alperaltuntas, or @sjsprecious do any of you know why I don't see the "Build iturbo branch of MOM6 with TIM and FMS" checks here?

[mwaxmonsky]

@mnlevy1981 Looks like the pull request branch list doesn't contain iturbo/dev-turbo.

[mwaxmonsky]

Also, because iturbo won't feed in to any other branch, we probably want to remove the push list or just change the list of branches that trigger this workflow on push to just iturbo.

[johnmauff]

The additional unit tests (located in turbo-stack) will not compile without the use of the iturbo version of MOM6, which is why I am thinking that there might need to be an iturbo version of turbo-stack.

[mnlevy1981]

@mnlevy1981 Looks like the pull request branch list doesn't contain iturbo/dev-turbo.

This is the turbo-stack repo, while iturbo and dev/turbo are MOM6 branches. What I was hoping for was a turbo-stack test that switches MOM6 from dev/turbo to iturbo and then tries to build everything.

The additional unit tests (located in turbo-stack) will not compile without the use of the iturbo version of MOM6, which is why I am thinking that there might need to be an iturbo version of turbo-stack.

Oh, I see. I should probably let go of this idea of running everything off turbo-stack's main branch, but it seems like we should be able to introduce something in build.sh to toggle whether optional unit tests are built or not... maybe it makes sense to talk about this Friday afternoon instead of trying to hash it out over github

[Copilot]

Pull request overview

Adds a new GitHub Actions workflow to build the instrumented MOM6 branch (dev/turbo-debug, “iturbo”) with both TIM and FMS2, aiming to catch submodule/branch integration issues earlier in CI. As part of enabling this, the PR also removes the CESM_share submodule and trims build logic that previously referenced CESM share source files.

Changes:

• Add a new CI workflow that checks out submodules/MOM6 at dev/turbo-debug and builds with TIM and FMS2.
• Remove CESM_share submodule from .gitmodules.
• Remove CESM_share shr_* source injections from the infrastructure build step in build.sh.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.

File	Description
build.sh	Removes CESM_share shr_* file appends from infra build path generation.
.gitmodules	Drops the src/CESM_share submodule entry.
.github/workflows/build-tests-iturbo.yaml	New workflow to build MOM6 dev/turbo-debug with TIM and FMS2 in CI.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mnlevy1981]

This PR is ready for review / merging, but I'm not sure who would be best for reviewing. It

1. Adds a test where we check out the dev/turbo-debug branch of MOM6 and then build the model (against both TIM and FMS2); the test wasn't running earlier because I had mis-indented a block in the YAML
2. Removes the CESM share code submodule and cleans up build.sh accordingly (I think a previous PR either here or in MOM6 stopped running through the #ifdef CESM_COUPLED branch that used share code, but the shared constants we were using are identical to the GFDL values so this change was bit-for-bit)