As part of our gradual migration to the Travis CI GitHub App, that now uses GitHub Checks to report build statuses, we kept posting both GitHub Checks as well as the old commit statuses for some time to not break repositories using the commit statuses in their protected branches settings and give time to do the change to use the new Checks instead.
As of October 4th, those repositories on travis-ci.com which are managed by GitHub Apps no longer receive updates to the GitHub Commit Status API. Instead, Build Statuses will be posted to the GitHub Check Runs API.
Remedy
To fix this issue, update your repositories using protected branches to require GitHub Checks as follows:
In the “Branch Protection Settings” section, click “Edit” for a protected branch
Scroll down to the second box, “Require status checks to pass before merging.” Select either “Travis CI - Pull Request” or “Travis CI - Branch” or both. (Note: “continuous-integration/travis-ci” is the Status API event which is deprecated)
This problem does not seems too be solved. I’m following these instructions to the letter, and there is no change whatsoever. This is the PR. Has there been any change lately on how things are running in Travis?
@BanzaiMan, thank you very much for the information. Yesterday, I transferred the repo to an organisation I am owner and didn’t realised that was affecting Travis. Now it is enabled again.
@webknjaz Oh, seeing this unconsistently is most curious as this case normally applies to people that have switched from webhooks to GitHub Apps at Travis CI and had a protected branch setup.
Do you have any more details on the behaviour you’re seeing / you’ve noticed? It may be something else.
I am experiencing this problem, with a stuck " Travis CI - Pull Request Expected — Waiting for status to be reported".
I do have a protected branch (master). However, it already had both “Require status checks to pass before merging” -> “Travis CI - Pull Request” and “Travis CI - Branch” checked.
In fact, I turned on the protected branch only a couple weeks ago, long after this November report of ‘legacy’ problems.
Hi @jrochkind, sorry I missed your reply. Are you still seeing the “waiting for status to be reported issues” could you share a link to a build for which this happened or reach out to our support team with more details? Thanks a lot.
Support verified this is a known issue using the Github “draft” PR feature
From May 12:
After looking into it, it seems that your PRs are using the new Draft Pull Request feature from GitHub, right? Unfortunately we don’t support it yet, and I think this is why builds aren’t triggering at the moment. Internally, since these PRs are “locked” on GitHub’s end, we’re receiving these events similarly as we receive the events when a PR is not mergeable.
I opened an internal issue for this so that our team can work together with GitHub on this feature, and in the meantime we’re also working to apply some changes in our end to make sure that these events are correctly reflected in the Requests page of the projects in Travis CI
[…]
We are sorry it’s taking so long to come up with “draft” PR support but I can assure you our team is working on it as we speak. Please keep an eye on our changelog to know if/when it’s released.
Putting this here publicly to provide some transparency on how long it will take to fix the problem caused by Github feature introduced Feburary 2019. (Am a bit dissapointed that I’m not sure travis knew about the problem until I reported it three months after it was released…)
Thanks for the prompt, reply @jrochkind. I can follow-up on the draft PRs topic Draft pull requests not being built about how those are coming up. Sorry for the hassle identifying this issue.
This regularly happens to us (maybe once a month or so, I didn’t measure it). E.g. right now on https://github.com/gap-system/gap/pull/3522 it says that it is waiting for Travis, but all Travis jobs completed successfully. In the past, I sometimes was able to workaround the problem by re-running one of the jobs, and that would resolve it (at the cost of a few extra minutes waiting). But recently this hasn’t work, also for this PR. The only option seems to be to trigger a full rebuild (e.g. by rebasing the PR and force pushing).
We have continuous-integration/travis-ci enabled via a branch protection rule for the master branch. As an experiment, I tried turning it off and back on again (sigh), but that didn’t help either. Any suggestion would be highly welcome! Because while I can probably fix this by restarting the build, that’ll take at least an hour to complete (one hour plus the time for all other running builds… so on some days it can be many hours). And so that’s not a good long-term solution.
Some attempts to post status updates were failing due to GitHub auth issues. Many of these are now resolved, from what I’ve seen in the logs, so if you are able, restarting the build (or a portion of it) may post the new update correctly.
