Known Issue: Travis CI reports "Expected - Waiting for status to be reported" on the GitHub Status API, but the status never arrives

Symptom

Your repository stopped receiving status updates. In your PR, you see something like this:

Explanation

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:

  1. Go to the repository’s Branch Settings page (https://github.com/OWNER/REPO/settings/branches).
  2. In the “Branch Protection Settings” section, click “Edit” for a protected branch
  3. 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)
  4. Save your changes

Original post here: https://github.com/travis-ci/travis-ci/issues/10204

2 Likes

That’s dec 16

Expected released dec 16 but there is a error

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?

@dalonsoa https://travis-ci.com/dalonsoa/solcore5 appears to have been disabled.

1 Like

@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.

FTR I’m seeing this sometimes (not consistently).

Also: I’ve hit this with other GitHub Apps which I’m developing so I assume the problem might be on the GitHub’s side.

@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.

I am kind of losing confidence in travis lately.

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.