Travis CI status not registered on the GitHub PR page

Hi there,

After converting to organization, we seem to have trouble with the triggered web hooks. Checking the settings shows that from a first look everything is in order, with all web hooks showing green ticks.

However, whenever we force push to each PR (or even master branch), only some web hooks return proper statuses and the previously working Travis CI status no longer shows up:

Checking for the trigger on the Travis CI side shows that everything triggered fine there, the only problem is in displaying the result on the page of the PR.

Has anyone experienced this before? Any help on what we should look out for is greatly appreciated.

My experience has been that whenever you force push the Travis status on GitHub WebUI can become erratic for a short while (ca. 15 min.), due to the repo history being changed, especially if previous builds are still being run or queued for the old (and now replaced) commits. In these cases, I tend to rely more on email notifications than the status info on the WebUI, especially so when force-pushed commits follow each other rapidly (e.g. less than 15 min. between each other).

But the problem might also be due to the repository settings affecting builds’ queues — i.e. whether new commits should cancel all previously running builds or end up being queued.

You might want to check Travis CI documentation » Building Only the Latest Commit:

If you are only interested in building the most recent commit on each branch you can use this new feature to automatically cancel older builds in the queue that are not yet running . Existing builds will be allowed to finish.

The Auto Cancellation Setting is in the Settings tab of each repository, and you can enable it separately to:

  • Auto cancel branch builds - cancels queued builds in your branch and appears in the Build History tab of your repository.
  • Auto cancel pull request builds - cancels queued builds for pull requests (the future merge result of your change/feature branch against its target) and appears in the Pull Requests tab of your repository.

As you can see, even with this setting enabled Travis will only cancel pending builds, so new commits’s builds will be queued to the currently running build. So, if your build takes 5 mins to complete and you force push every 4 minutes, your last commit will always end up waiting in the queue and the WebUI status gets messy because it has the status info for previous commits that are no longer part of the repo history and is waiting for info on the new commit(s) that replaced them.

Hi @tajmone, these are good points, however the issue appears even with less frequent pushes and the travis status status will not appear on the PR GitHub page even after days. So somehow this is related to the feedback from the Travis CI.

I also posted in the Travis CI community forum and didn’t get any replies there. The fact that we only got this after converting to organization and it only appears on the GitHub page made me decide to post here too.

Hard to say if it’s a bug or a problem with the Internet.

In the past week I’ve experienced many problem with Internet related services, in general, ranging from intermittent availability to lag times (many web pages often can’t load CSS files or images). A quick search revealed that the COVID19 lockdown in some geographic areas is responsible for this — lack of adequate servers maintenance, etc. So much so that even major players have temporary reduced some services (e.g. WhatsApp has temporary reduced the number of video conference participants).

So chances are that it might be due to temporary network problems — summer time is always problematic for network services, with many people being on holiday, and partly due to the heat affecting many devices; add to that the fact that since the COVID lockdown more people have been connecting to the Internet (online school classes, employers working from home, or just people having more time to watch streaming TV) and the reduced labor force to maintain infrastructures, all of these making this summer worst than others.

The Travis status on GH’s WebUI is quite entangled, which doesn’t help — e.g. sometimes the status badge images won’t refresh on the repo README by a simple F5 page refresh, clinging to the cached image instead of the latest one. But the Travis email notifications are always reliable — but again, as of lately some emails take very long to reach destination (e.g. last week a purchase receipt from a huge corporation took three days to deliver).

The thing is again, it is something we have been experiencing for 1-2 months now after waiting for long enough for the Travis community replies.

Also, as I mentioned above this issue occurred together with conversion to a GitHub organization so this timing doesn’t seem too coincidental.

I often transfer repositories from my personal account to other organizations, but haven’t experienced this problem so far.

That’s a long time indeed, if no commit build ever worked as expected than something is indeed wrong.

It seems that some permissions were still lacking on the side of the organization even though we reconnected all apps and completed them before. So anyone else getting such troubles, make sure to double check all of your github app permissions for the organization.