Combining checks into one and dealing with skipped runs #88
Conversation
|
Also: I that the only way to totally fix #87 will be to make the coverage check not required. |
The latter part of #87? If so, I'm fine dealing with the uncompleted checks if fixing it means disabling the coverage requirement, because we're really gonna need to enforce the coverage checks as development starts ramping up. |
Hmm, not good; I'll check that out. |
|
Yeah - that's what I meant! I don't think that we can have the coveralls report be a required check if we're not going to run the tests for some pull requests because coverage won't be reported for those cases. It'll still show up as a failure on the pull request, but merging won't be blocked. This PR is ready for review now, I think. It adds an "All tests" check that reports the results of all the matrix builds. Once the action finishes running, we can make that the required check. The jax test is still failing, but this pull request can't have caused any of those so I'm a bit confused. |
My guess is that it has to do with some (effectively) random test values. |
|
Nope, I was wrong, it's due to a recent |
|
Relevant issue: #89 |
|
Are we uploading the coverage for every matrix job? |
|
Yes, but those don't get displayed on coveralls until the final job where coveralls is told to "finish" and combine all the steps. This is the recommended procedure for coveralls on actions. |
|
@brandonwillard: In response to your implied concern I switched to merging the coverage results in place and then uploading them once. That way the "checks" tab doesn't get spammed. It looks like it worked so this should be good to go. |
Many thanks! It doesn't appear to be a real problem, but it is a bit jarring in some ways. |
2 participants
I believe that this will fix #87.
I'm finding that some of the jax tests are failing on my fork though:
tests/sandbox/test_jax.py::test_extra_opsfails with: