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.
I was trying to apply the Remedy, but in my branch protection section only appears the old
continuous-integration/travis-ci option.
Iâm not seeing âTravis CI - Pull Requestâ nor âTravis CI - Branchâ option to be checked.
Of course, installed Travis GitHub Apps on my project.
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.
