Conversation
.github/workflows/ci.yml
Outdated
|
|
||
| # Test production branch | ||
| curl -O -L https://raw.githubusercontent.com/illinois-ceesd/emirge/main/switch-mirgecom.sh | ||
| chmod a+x switch-mirgecom.sh | ||
| ./switch-mirgecom.sh prod | ||
| examples/run_examples.sh ./examples |
There was a problem hiding this comment.
| # Test production branch | |
| curl -O -L https://raw.githubusercontent.com/illinois-ceesd/emirge/main/switch-mirgecom.sh | |
| chmod a+x switch-mirgecom.sh | |
| ./switch-mirgecom.sh prod | |
| examples/run_examples.sh ./examples | |
| # Test production drivers | |
| . .ci_support/production_testing_env.sh | |
| . .ci_support/merge-install-production-branch.sh . | |
| . .ci_support/production-drivers-install.sh . | |
| . .ci_support/production-drivers-run.sh . |
There was a problem hiding this comment.
This should run the production tests kind of in the same sort of way as the regular examples are exercised. The big difference here is that the "production" branch will be merged first.
| if test "$DOWNSTREAM_PROJECT" = "mirgecom"; then | ||
| # Test main branch | ||
| examples/run_examples.sh ./examples | ||
| fi |
There was a problem hiding this comment.
Maybe this should be a separate CI job? mirgecom is already the longest job in grudge, I'm reluctant to make CI turnaround even more sluggish.
There was a problem hiding this comment.
Then maybe drop the downstream pytest (which takes a long time)? Running the examples (typically done within 10 minutes) will be enough and much faster. The examples won't work if MIRGE-Com is broken, and they will also fail if they get anything outside the accepted solution range.
There was a problem hiding this comment.
|
|
||
| if test "$DOWNSTREAM_PROJECT" = "mirgecom"; then | ||
| # Test main branch | ||
| # Only test examples, not pytest tests, as those take too much time. |
There was a problem hiding this comment.
Why not add a separate job for examples instead of not running mirgecom pytest at all?
There was a problem hiding this comment.
Imo, running the pytest suite for the downstream project is of little value. It also takes a really long time (only 30 minutes for mirgecom@main, but pushing an hour+ once NS+AV tests are added). I think making sure the examples run and get the correct answers is a sufficient amount of testing to claim the current development does not break mirgecom.
There was a problem hiding this comment.
OK, fair. You're on the receiving end of those potentially breaking changes, so if you say it's OK, I'm happy to trust you and take my shorter CI times. :)
104a00d to
de84ea5
Compare
cc: @MTCam
Could help with catching illinois-ceesd/mirgecom#617
cc: #222