always mark Python 3.11 jobs as successful #182
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow-up to #176.
#176 added Python 3.11 build and test jobs. It tried to make those optional by using GitHub Actions'
jobs.<job_id>.continue_on_error
mechanism (docs on that).Unfortunately, it seems that that mechanism doesn't play nicely with RAPIDS branch protections, which use one more job that runs at the end of the
pr
workflow and declares all other sets of jobs in aneeds:
block.cudf
example: https://github.com/rapidsai/cudf/blob/8526e6d5b21361465d1c72ecbea64d3d2d9bf849/.github/workflows/pr.yaml#L13-L34.As a result, the Python 3.11 jobs were actually blocking CI in repos where they were failing.
This proposes the following changes:
continue-on-error
How I tested this
Opened rapidsai/cudf#15172 to test.
On the first run, I saw all Python 3.11 marked as successful, even though their logs clearly indicated that they failed.
(build link)
TODO: once that completes, I'll do one more build that breaks the tests and shows that the non-Python-3.11 jobs are marked as failed.Proposing that we merge this without waiting on that test, to unblock CI for
cudf
(and maybe other projects).