-
-
Notifications
You must be signed in to change notification settings - Fork 60
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
PR checks hang because travis does not report back to github #376
Comments
Latest changes related to Travis CI. Travis CI migrated from legacy API to new GitHub Action API: #371 Removal of old webhooks: #374 Travis CI can be reported/discussed at: https://travis-ci.community/ |
Another pointer: the same issue reported by @vsajip on discourse https://discuss.python.org/t/pull-request-required-checks-travis-build-stalled-again/5247 It's again the case of two travis checks getting spawned off and one being stuck. |
I created #377 "Please make Travis CI optional again". |
Same thing on a 3.8 backport here: python/cpython#22707. Advice on how to proceed? I'm not sure why two identical Travis builds were created in the first place. |
It's a bug on Travis's end. Short term you can try closing and re-opening the PR. Failing that, you can follow Ned's advice from here and reach out to the release manager to override the check: https://mail.python.org/archives/list/python-dev@python.org/thread/4TNKVOJ2LUJZZHHIBNORZ7GIVMYMNDER/ Long term, I think Travis is going to be disabled as a required check in favor of the Ubuntu Github workflow as per Victor's linked issue above. |
Yeah... I tried that right away. Turns out our bots will delete their branch if you close a backport PR, meaning you can't reopen it: python/cpython#22703 So I reapplied the backport label and the new one's stuck too. Nothing urgent though, so I'll try waiting to see what ends up happening with our CI config before bugging more people. :) |
This issue was fixed by #377 which made Travis CI optional again: |
This issue has been resolved thanks to Ned Deily by manually bypassing the check requirement as a release manager. I'll report it anyway as requested by @vstinner. It seems generally unresolved and therefore may require further manual action in the future.
The checks of a simple documentation PR was hanging for several days, waiting for a travis success result.
python/cpython#22464
However, the travis run had already succeeded very quickly:
https://travis-ci.com/github/python/cpython/builds/187435578
and github just failed to pick up the response, leaving the travis job status as "created" instead of "passed".
https://github.com/python/cpython/pull/22464/checks?check_run_id=1188595760
Neither a close-reopen cycle of the PR in github, nor a manual rebuild trigger in travis fixed the issue.
Creating a new PR from the same branch also did not bring any change, since github and travis apparently managed to reconnect the new PR to the "running" build, without looking at the result.
The text was updated successfully, but these errors were encountered: