Resources suggested by @tomvothecoder:

CI/CD runners on HPC machines instead of on cloud:

• About self-hosted runners - GitHub Docs
• GitLab Runner | GitLab

Next steps

• Create a bash script to automate these steps
• Determine if the script can be run via GitHub Actions

Thank you for getting to it. I think this will benefit in the long run, we can try to get this in for next unified. In terms of time-line, let's try prioritize those user-facing features (i.e. land support, zstash update, cdat migration) the land support needs lots of interaction with science team to finalize.

Yes, that timeline sounds good to me. I just wanted to get an idea of what issues we would face here.

#628 added 20 unit tests. Integration tests are really where we need further automation. Further action items:

• Address the TODO items in Automate zppy tests #520. If we can get those steps automated, then we can effectively automate the entire process described at https://docs.e3sm.org/zppy/_build/html/main/dev_guide/release_testing.html
• Once Automate zppy tests #520 is merged, we'll have a process we can run automatically every week. Ideally, we could set up some sort of cron process to run the Weekly tests weekly (rather than manually running them weekly).
• Once the weekly tests are running automatically, it would further help to run some of the min-case cfg files automatically as well. Specifically, it would be great to have some sort of "if file was changed in this PR or recent commit history, then run min-case-X cfg" setup.
• Look into mocking external dependencies rather than relying on real data paths, which can be finicky. Hackathon ideas for zppy #629 describes this further

@tomvothecoder noted --y on mamba may allow automatic bypass of the y/n user prompts.