also test production drivers#224
Conversation
|
|
||
| # Test production drivers | ||
| source .ci_support/production_testing_env.sh | ||
| source .ci_support/merge-install-production-branch.sh . |
There was a problem hiding this comment.
Down inside there there is a pip install -r requirements.txt after merging with production. Will that mess stuff up, or switch the grudge branch? Edit: Could just sed out the grudge part of it?
inducer
left a comment
inducer
left a comment
There was a problem hiding this comment.
I'm not sure I'm sold. I'm happy to keep mirgecom main working. Production, by definition, depends on a lot of unmerged stuff (including, potentially, grudge changes), so I feel this would be a high-maintenance proposition.
| # Test main branch | ||
| examples/run_examples.sh ./examples | ||
|
|
||
| # Test production drivers |
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.
Edit: I mean to suggest downstream examples is enough, full stop. No production testing either, as you suggested.
As an added bonus, this provides an incentive to not let production and main drift too far apart. |
I don't think neglecting production testing in grudge CI will affect the amount of drift between mirgecom@production and mirgecom@main. That said, I do not disagree with your notion leave it out. |
inducer
force-pushed
the
ci_mirgecom_examples
branch
from
104a00d to
de84ea5
Compare
3 participants
No description provided.