I’ve been reviewing pull request 22276, which is stalled on a Travis CI check. It was previously stalled on the same, and I closed and reopened the PR, but it’s stalled again. The check is required, and its details page on GitHub indicates there are five jobs, whose states are either “created” (1 job) or “queued” (4 jobs). However, following the links to these individual jobs shows that these jobs have all passed, according to the page on Travis.
This has happened before on other PRs (sometimes on documentation-only builds) - closing and reopening the PR has usually resulted in checks passing. Does anyone know what might be causing this lack of synchronisation between GitHub and Travis, or any quick way to re-sync? Obviously repeatedly closing and reopening could be tried, but it seems like a bit of a time sink.
If this issue comes again, one option would be to make Travis CI non-voting. Another option would be to remove Travis CI and only rely on the Ubuntu job of GitHub Action.
I’m kind of tired of all the Travis CI bugs that we have for one year…
Thanks for the pointer, Victor. I tried that too, multiple times. Unfortunately, the result is the same - the Travis page reports all tests passing, but the “Checks” tab on the pull request still shows the Travis jobs with the wrong status values (1 “created”, 4 “queued”). I would have expected the GitHub “Checks” tab to have some way to manually re-sync with Travis, but couldn’t see anything obvious that does that. I presume these checks are something CPython developers wrote/configured - any pointers as to where that source might be?
One passed, the other is the stalled one. I looked at some other PRs randomly, and found some where:
the Travis check is added twice, and one completed but the other is stalled (e.g. this PR)
the Travis check is added once, and appears to have completed OK (e.g. this PR).
Could this be something to do with how we’ve configured GitHub actions? I could dig into it, but I suppose whoever set up the GitHub Action stuff might spot something more quickly than I will (as I currently know nothing of that API). Perhaps @EWDurbin or @Mariatta might have some pointers?
Bizarrely enough, their problem was that a fork of their repo still had the old webhook installed. Fairly confident that this is some sort of travis bug so your best bet might be to bump that thread and try to get the attention of travis staff there.
I’ve mentioned this issue with GitHub in GitHub OS Maintainers Feedback Forum. I suggested that perhaps they can detect the duplicated status check and handle it accordingly.
Regarding this issue of duplicated CI check, I got this reply one hour ago:
“A fix has gone out for this to avoid duplicate status checks being created. You shouldn’t see this behaviour any more, let us know if you do though. Thanks again for the report!”
