-
Notifications
You must be signed in to change notification settings - Fork 217
ci: replace single gating check with wait-for-status-check
[no-ci]
#1008
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
b455cfe
to
7a583d3
Compare
7a583d3
to
6b6844a
Compare
/ok to test 6563550 |
This comment has been minimized.
This comment has been minimized.
6563550
to
d1ec467
Compare
/ok to test |
Auto-sync is disabled for ready for review pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
/ok to test |
Check job still completes instead of spinning: https://github.com/NVIDIA/cuda-python/actions/runs/18165463144/job/51706593048?pr=1008 |
@leofang Can you paste the names of the checks here from the UI? I can't see them because I don't have access. |
Once we are sure the check job completes the last, we can either adjust the repo setting and then merge, or admin-merge then adjust the repo setting. But we are not there yet. The repo setting is irrelevant of the failure of waiting for dependent jobs here. It is just a workflow bug that we should fix first. |
/ok to test |
1 similar comment
/ok to test |
I'm going to try one more alternative to avoid the action entirely. |
I really don't like having to add an arbitrary delay to get this to work. |
Yeah adding a random delay is flakey. It could proceed to complete when build jobs finish but the test jobs are still being spawned. Not a fan either. |
/ok to test |
3 similar comments
/ok to test |
/ok to test |
/ok to test |
wait-for-status-check
wait-for-status-check
[skip ci]
/ok to test |
/ok to test |
I applied it. You can see it now becomes "required". I haven't removed the old check yet. But I am confused: If this is required, we still need to execute |
The new status check job should be considered passing, because it's skipped, according to that documentation. I'm try to taking advantage of the fact that skip == success. |
wait-for-status-check
[skip ci]wait-for-status-check
[no-ci]
/ok to test |
8203214
to
1685f32
Compare
/ok to test |
@leofang It looks like the |
I am checking. This is odd because as discussed earlier once a CI job is run, it should appear as a registered job in the repo setting's dropdown menu, but for some reason I had to type the full name explicitly without anything popping out for me to choose. |
@cpcloud I think I fixed it. It's just "Check job status" (without "CI"), see the last row: |
Yep, that has to be removed before merge is allowed. |
Let me check quickly. btw we'll need to backport this PR to 12.9.x. Keith applied the same ruleset to all branches. |
It works now! To avoid race condition I am merging immediately. |
Thanks for the review, much appreciated! |
Thanks for working this out Phillip! |
|
This PR changes our usage of
status-check.yml
to allow skipping CI when the head commit of PR contains the text[skip ci]
.Our current usage of the
wait-for-check
action doesn't sense to me.We have as inputs all the checks that we care about
build
,test*
,docs
,and we only invoke that action when those succeed.
That seems to be no different than running
exit 0
againstubuntu-latest
andthus defeats the purpose of using
wait-for-checks
which is to allowfiner-grained control over what is actually a required check.
In our case, there are cases such as #999 where it doesn't make sense to do
a full build test docs run, but developers are left waiting on an admin to
merge their PR.
Proposal for merging this PR:
I don't have permissions to do that, so someone other than me needs to do
that.