Pull request required checks - Travis build stalled, again

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.

@vstinner has been fiddling with Travis lately so he may have some ideas.

One month ago, we had issues with legacy Travis CI, but Python moved to the new GitHub Action API: https://github.com/python/core-workflow/issues/371

Two weeks ago, there were issues with a remaining “webhook”, Ernest removed it: https://github.com/python/core-workflow/issues/374

Obviously repeatedly closing and reopening could be tried, but it seems like a bit of a time sink.

There is no need to close/reopen the PR, which reschedules all CI jobs.

For your recent (3 days ago) issue, I suggest you to first attempt to go to https://travis-ci.com/github/python/cpython/builds/184943820 and click on (Restart build).

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…

1 Like

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?

You can try to dig into https://travis-ci.community/ which is the official way to report issues to Travis CI.

I just noticed that for the problematic PR, the “Travis CI - Pull Request” check appears to have been added twice:

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?

There’s a thread with this exact same symptom on the Travis forums: https://travis-ci.community/t/duplicate-job-attempts-for-pr-builds-causing-queued-build-created-problems/9776/4

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.

Thanks for the pointer - I’ll try that.

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.

1 Like

The python/cpython project was forked 16.1k times… Do we really have to manually check all these forks? :smiley:


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!”


Just to clarify - that message is from GitHub, not Travis, right?

Ah yes from GitHub