Closed cwsmith closed 3 years ago
@jacobmerson @mortezah Travis CI stopped working a few months ago for unknown reasons (it was set it up by someone else years ago). Earlier this year the SCOREC organization was moved to the RPI enterprise license, and, from what I understand, this gives us a lot of github 'action' minutes. Given those changes, and that I'd prefer to avoid third-party apps when possible, this PR replaces travis CI with github actions.
The PR builds core with GNU and Clang and minimal features (i.e., no zoltan, simmetrix, etc.) and then runs ctest on both. The builds are triggered for pushes and pull requests to develop. Note, nightly testing happens elsewhere before develop is merged into master.
Do you have any objections to this revised CI setup?
Note, the test failures are discussed here: https://github.com/SCOREC/core/pull/344#issuecomment-879137143
In theory this seems like a good idea. I don't know much about the CI landscape. The idea is that we test on whatever ubuntu's standard g++/clang++ compilers are for every pull request correct? Do we maintain a list of supported compilers? If so, do we test those nightly, or before develop->master?
Do we maintain a list of supported compilers?
There is no list of list of supported compilers.
If so, do we test those nightly, or before develop->master?
The nightly test just uses GNU compilers.
on whatever ubuntu's standard g++/clang++ compilers
Basically; there are a few choices per Ubuntu version. I'm using the defaults.
for every pull request correct
This is only triggered for PRs to develop.
Splitting the action into a setup step that downloads the meshes and installs dependencies (i.e., mpich) and then the matrix of builds is not possible as each job may run on a different VM. See https://stackoverflow.com/questions/65242830/in-a-github-actions-workflow-is-there-a-way-to-have-multiple-jobs-reuse-the-sam