GitHub Actions CI: CPU build tests for GNU, Intel OneAPI, and NVHPC by cenamiller · Pull Request #1524 · MPAS-Dev/MPAS-Model

cenamiller · 2026-10-05T21:19:19Z

Replaces #1469 (closed prematurely).

Adds initial GitHub Actions CI for MPAS-A: build tests for the
atmosphere and init_atmosphere cores with GNU, Intel OneAPI, and
NVHPC compilers and MPICH on CPU. This is a subset of the testing
developed on the NCAR/MPAS-Model-CI fork.

Each workflow:

Builds atmosphere, then init_atmosphere in the same source tree
(skipped if atmosphere fails), in NCAR hpcdev containers on
GitHub-hosted runners. Double precision and SMIOL are the defaults.
Runs on new PRs against develop (or when someone pushes a new
commit to an open PR) and on push to master.
Prints compiler and library versions and the build command in the
run summary, and uploads the build logs as an artifact
(build-logs-<sha>-<compiler>-<mpi>-<io>-<precision>, kept 7 days).

More tests and build options are available on the NCAR/MPAS-Model-CI
fork and can follow in future PRs.

Files:

.github/ci-config.env: container images and make targets
.github/actions/build-mpas/: builds an MPAS core
(print-build-env.sh prints versions and the build command)
.github/actions/resolve-container/: resolves the container image
.github/workflows/_build-compiler.yml: reusable build workflow
.github/workflows/build-{gcc,intel,nvhpc}-mpich.yml: 3 callers

Developed in NCAR/MPAS-Model-CI. Claude assistance.

cenamiller · 2026-10-05T21:25:43Z

Depending on what science changes have been merged into develop at the same time, we shouldn't expect the ect to pass until I generate a new summary file. But let's see!

mgduda · 2026-10-05T21:58:35Z

@cenamiller Thanks for this new PR!

mgduda · 2026-10-05T22:16:58Z

@cenamiller @abishekg7 Following up on the comments from PR #1469 (which this PR replaces), I agree with most of them, and I'm fine with addressing some of them (e.g., adding build tests for the init_atmosphere core, and adding a CMake build test) with a future PR.

Is it the case as of now that all of the tests will run with every push to a PR branch?

abishekg7 · 2026-10-05T22:23:17Z

@cenamiller @abishekg7 Following up on the comments from PR #1469 (which this PR replaces), I agree with most of them, and I'm fine with addressing some of them (e.g., adding build tests for the init_atmosphere core, and adding a CMake build test) with a future PR.

Is it the case as of now that all of the tests will run with every push to a PR branch?

It is now a pared down set of tests, but yes, they will be triggered with every push to a PR branch.

cenamiller · 2026-10-05T22:34:53Z

Hi, yes, agreed with Abishek. I've been thinking about this. It may be nice to have the "runs on every push to a PR" branch feature for a bit, because it makes it easier to trigger tests on old PRs, with just a push. Otherwise, contributors would need to close/reopen the PR in order to trigger tests. But once we've run them on some old PRs, we can very easily turn that trigger off. And anyway, if the tests make it to the default branch, you'll be able to manually dispatch tests when you think it's appropriate and we won't be so beholden to an automatic trigger.

mgduda · 2026-10-06T20:06:24Z

@cenamiller @abishekg7 What do you all think about (1) removing the ECT tests from this PR, and (2) adding build tests for the init_atmosphere core to this PR? My thinking is that build tests for both the init_atmosphere and atmosphere cores are probably of greatest value right now, and omitting the ECT tests would help to reduce the amount of time all of the checks will typically take to complete.

cenamiller · 2026-10-06T20:21:43Z

@mgduda Yes, we can do that! It won't take very long to set up, but I don't have those tests ready as stand-alones. I can submit them before lunch tomorrow though. Would you like them to run on the same triggers as these? And which compilers for each? The options for 'just build' would be GNU, Intel OneAPI, NVHPC (for CPU) and NVHPC+OpenACC. And for sides we have PIO/SMIOL and MPICH/OpenMPI.

mgduda · 2026-10-06T20:34:31Z

@mgduda Yes, we can do that! It won't take very long to set up, but I don't have those tests ready as stand-alones. I can submit them before lunch tomorrow though. Would you like them to run on the same triggers as these? And which compilers for each? The options for 'just build' would be GNU, Intel OneAPI, NVHPC (for CPU) and NVHPC+OpenACC. And for sides we have PIO/SMIOL and MPICH/OpenMPI.

In the interest of keeping everything as simple as possible for now, would it be reasonable to add an extra step to the build workflows to compile the init_atmosphere core before or after we compile the atmosphere core? When building a second core within an MPAS-Model source tree that already has another core (along with the shared infrastructure) compiled, the incremental cost of building the second core is not so bad. Going this route would suggest we use the same build matrix as for the atmosphere core: GNU+MPICH for Intel oneAPI, NVHPC, and GNU.

abishekg7 · 2026-10-06T20:47:17Z

I think keeping the existing build matrix and triggers, and just adding the build of init_atmosphere core as a step sounds good. Perhaps init_atmosphere core can be built before the build of atmosphere?

mgduda · 2026-10-06T22:35:30Z

I think keeping the existing build matrix and triggers, and just adding the build of init_atmosphere core as a step sounds good. Perhaps init_atmosphere core can be built before the build of atmosphere?

Adding a build of the init_atmosphere core before the build of the atmosphere core sounds fine to me. (Perhaps it's over-optimizing, but my suspicion is that more code is changed in the atmosphere core than in the init_atmosphere core, so building the atmosphere core first may help us to catch build errors introduced by a PR a bit sooner. Ultimately, though, the time savings either way may not be significant enough to influence our decision on which core to build first.)

Build the atmosphere and init_atmosphere cores in NCAR hpcdev containers on GitHub-hosted runners, atmosphere first, in one source tree. Each run saves compiler and library versions, the build command, and build logs. Runs on PRs against develop and on push to master.

cenamiller · 2026-10-16T15:21:40Z

Squashed to a single commit and rebased onto the current develop, as requested. No file changes.

abishekg7 · 2026-10-23T19:02:52Z

+
+        # Set up I/O configuration
+        if [ "${{ inputs.use-pio }}" = "true" ]; then
+          export PIO_ROOT=${PIO_ROOT:-/container/pio}


I think this should be PIO, not PIO_ROOT. According to the MPAS Makefile

abishekg7 · 2026-10-23T19:25:01Z

+          persist-credentials: false
+
+      # atmosphere first: it is the more likely to fail
+      - name: Build atmosphere (${{ inputs.precision }} precision, ${{ inputs.io }})


Would it make sense to do the init_atmosphere CORE step first and then atmosphere? I'm thinking about keeping the atmosphere executable to run ECTs later on, etc. Or are these executables cached anyway, and the make clean step doesn't matter as much?

abishekg7 · 2026-10-23T19:30:51Z

+          echo "::error::${PRINT_ENV} not found"
+          exit 1
+        fi
+        export COMPILER_FAMILY MAKE_TARGET ARCH CLEAN_CMD MAKE_CMD


Claude suggested this issue. I haven't double checked it myself.

make-flags gets split on spaces. ${MAKE_CMD} and ${CLEAN_CMD} run unquoted. A value like FFLAGS_OPT="-O2 -g" reaches make as two broken words, and any * or ? gets expanded as a filename pattern. Building the command as a bash array would fix it.

abishekg7 · 2026-10-23T19:32:11Z

+  build-timeout:
+    description: 'Build timeout in minutes'
+    required: false
+    default: '20'


Could this be bumped up a bit? As we're building two CORES now?

abishekg7 · 2026-10-23T19:34:14Z

+          export USE_PIO2=true
+        else
+          unset PIO
+          export USE_PIO2=false


USE_PIO2 just needs to be unset I think

abishekg7 · 2026-10-23T19:48:57Z

I'm adding a bunch of tasks as issues (to my fork) that can be addressed in the second iteration of the CI. Feel free to ignore them for now.

mgduda requested review from abishekg7 and mgduda October 5, 2026 22:04

mgduda added Atmosphere CI only Changes only affect CI, not the code or documentation labels Oct 5, 2026

mgduda mentioned this pull request Oct 5, 2026

GitHub Actions CI: CPU compilers with ECT validation #1469

Merged

cenamiller force-pushed the feature/ci-cpu-testing branch from 2268943 to 96b9518 Compare October 16, 2026 15:21

cenamiller changed the title ~~GitHub Actions CI: CPU compilers with ECT validation~~ GitHub Actions CI: CPU build tests for GNU, Intel OneAPI, and NVHPC Oct 16, 2026

abishekg7 reviewed Oct 23, 2026

View reviewed changes

abishekg7 mentioned this pull request Oct 23, 2026

CI: physics externals and MPAS-Data are downloaded during the timed make, on every run abishekg7/MPAS-Model#6

Open

Conversation

cenamiller commented Oct 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cenamiller commented Oct 5, 2026

Uh oh!

mgduda commented Oct 5, 2026

Uh oh!

mgduda commented Oct 5, 2026

Uh oh!

abishekg7 commented Oct 5, 2026

Uh oh!

cenamiller commented Oct 5, 2026

Uh oh!

mgduda commented Oct 6, 2026

Uh oh!

cenamiller commented Oct 6, 2026

Uh oh!

mgduda commented Oct 6, 2026

Uh oh!

abishekg7 commented Oct 6, 2026

Uh oh!

mgduda commented Oct 6, 2026

Uh oh!

cenamiller commented Oct 16, 2026

Uh oh!

abishekg7 Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

abishekg7 Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

abishekg7 Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

abishekg7 Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

abishekg7 Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

abishekg7 commented Oct 23, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

cenamiller commented Oct 5, 2026 •

edited

Loading