Travis CI - **Branch** Expected — Waiting for status to be reported

Travis CI Discussions & Feedback
1

Travis CI status check awaits branch reporting for PR builds that are not from the same repo.

image
image.png789×417 36.7 KB

It hangs forever. How to fix it? Recreating PR doesn’t help.

1 Like
2

Hello, there. Looks like your upstream repository requires this check to pass.

New_branch_protection_rule
New_branch_protection_rule.png1044×712 76.4 KB

You can either

  1. Ask your upstream repository to change this configuration, or
  2. Enable Travis CI for your fork. https://travis-ci.com
2 Likes
3

Upstream wants to run tests for their branches for sure. And I don’t think they want to force all people to turn on Travis for sending PRs. Is there any way to get a green status on PRs without turning off branch testing or forcing PR authors to get through the process of Travis setup for every clone?

4

Sorry, but there isn’t . The upstream is requiring the push build, so you have to work with that policy.

5

What is the push build?

Upstream is requiring testing PRs and own branches. If PR is tested, the PR branch is tested too. What the point in testing the PR branch twice?

6

A “push build” is one that is triggered by a commit to a branch. The one you are not running.

If PR is tested, the PR branch is tested too.

This is not true. Your topic branch and the base branch can diverge since you’ve started working on the topic branch, and the merge commit (which creates the PR build) can have significant problems. It is up to the repository owners which builds to run.

7

I still don’t get it. When I create PR, the code that is tested by PR check is the PR branch. If I push to that PR branch it is again tested by the PR check in this “push build”.

Now, where is the the code that is checked by the Branch check?

8

“Branch check” runs on your fork. Because you don’t have Travis CI activated on your fork, the check never runs, and the check never arrives.

1 Like
9

I am confused. Is “PR branch” that is tested by PR check and “branch in my fork” that is tested by Branch check is the same branch?

10

“PR build” is the merge commit upstream and the “branch build” is for your fork’s topic Branch. They are different.

11

How can this be? A merge commit is only created after a branch – i.e. the PR – is merged. A check runs before that.

Testing exactly what the codebase would be after merge is rather achieved with the practice of “linearized commits”. In Github, it’s implemented by the “Require branches to be up to date before merging” check – Travis checks have nothing to do with it.

12

This is not true. GitHub makes it available before the merge. Otherwise, we can’t test it before it is merged, can we? See https://travis-ci.com/Multy-io/Multy-back/builds/91361772#L345-L362 for what actually happens during the PR build.

2 Likes
13

Now it is more clear. Is +refs/pull/99/merge is a merge commit to master? Is it always to master HEAD or to the commit that PR was forked from? The link above doen’t list any hashes.

Now that this is clear, what is the point in making downstream branch builds for PRs that will be merged to master using this +refs/pull/99/merge that is already tested?

I don’t want to disable branch builds for upstream, because there are features developed that need to be tested.

14

Is it always to master HEAD or to the commit that PR was forked from?

My understanding of the GitHub’s API is that it is the latter.

what is the point in making downstream branch builds for PRs that will be merged to master using this +refs/pull/99/merge that is already tested?

I think I’ve answered this in an earlier comment. Travis CI - **Branch** Expected — Waiting for status to be reported - #6 by BanzaiMan