Uh oh!
There was an error while loading. Please reload this page.
ci: replace single gating check with wait-for-status-check [no-ci] - #1008
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. |
Uh oh!
There was an error while loading. Please reload this page.
b455cfe to
7a583d3CompareUh oh!
There was an error while loading. Please reload this page.
7a583d3 to
6b6844aCompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
leofang
commented
Oct 1, 2025
/ok to test 6563550 |
This comment has been minimized.
This comment has been minimized.
Uh oh!
There was an error while loading. Please reload this page.
6563550 to
d1ec467Comparecpcloud
commented
Oct 1, 2025
/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. |
cpcloud
commented
Oct 1, 2025
/ok to test |
leofang
commented
Oct 1, 2025
Check job still completes instead of spinning: https://github.com/NVIDIA/cuda-python/actions/runs/18165463144/job/51706593048?pr=1008 |
cpcloud
commented
Oct 1, 2025
@leofang Can you paste the names of the checks here from the UI? I can't see them because I don't have access. |
leofang
commented
Oct 1, 2025
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. |
cpcloud
commented
Oct 1, 2025
/ok to test |
1 similar comment
cpcloud
commented
Oct 1, 2025
/ok to test |
cpcloud
commented
Oct 1, 2025
I'm going to try one more alternative to avoid the action entirely. |
cpcloud
commented
Oct 1, 2025
I really don't like having to add an arbitrary delay to get this to work. |
leofang
commented
Oct 1, 2025
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. |
cpcloud
commented
Oct 1, 2025
/ok to test |
3 similar comments
cpcloud
commented
Oct 1, 2025
/ok to test |
cpcloud
commented
Oct 1, 2025
/ok to test |
cpcloud
commented
Oct 1, 2025
/ok to test |
wait-for-status-checkwait-for-status-check [skip ci]cpcloud
commented
Oct 1, 2025
/ok to test |
cpcloud
commented
Oct 1, 2025
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]cpcloud
commented
Oct 1, 2025
/ok to test |
8203214 to
1685f32Comparecpcloud
commented
Oct 1, 2025
/ok to test |
cpcloud
commented
Oct 1, 2025
@leofang It looks like the |
leofang
commented
Oct 1, 2025
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. |
leofang
commented
Oct 1, 2025
leofang
commented
Oct 1, 2025
@cpcloud I think I fixed it. It's just "Check job status" (without "CI"), see the last row: |
cpcloud
commented
Oct 1, 2025
Yep, that has to be removed before merge is allowed. |
leofang
commented
Oct 1, 2025
Let me check quickly. btw we'll need to backport this PR to 12.9.x. Keith applied the same ruleset to all branches. |
Uh oh!
There was an error while loading. Please reload this page.
leofang
commented
Oct 1, 2025
It works now! To avoid race condition I am merging immediately. |
cpcloud
commented
Oct 1, 2025
Thanks for the review, much appreciated! |
leofang
commented
Oct 1, 2025
Thanks for working this out Phillip! |
|


This PR changes our usage of
status-check.ymlto allow skipping CI when the head commit of PR contains the text[skip ci].Our current usage of the
wait-for-checkaction 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 0againstubuntu-latestandthus defeats the purpose of using
wait-for-checkswhich 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.