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

**URL:** <https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829>\
**Category:** Travis CI Discussions & Feedback\
**Tags:** github-integration\
**Created:** [November 12, 2018, 1:55pm UTC](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829 "2018-11-12T13:55:51Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![abitrolly](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/abitrolly/32/408_2.png) [@abitrolly](https://travis-ci.community/u/abitrolly)\
**Post date:** [November 12, 2018, 1:55pm UTC](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829/1 "2018-11-12T13:55:51Z")

</div>

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

 ![image](https://us1.discourse-cdn.com/flex015/uploads/travis_ci/original/1X/0440fcd764215e156c300ae392c1307005b08921.png)

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

> <https://github.com/Multy-io/Multy-back/pull/99>

---

<div class="post-metadata">

**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\
**Post date:** [November 13, 2018, 1:25pm UTC](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829/2 "2018-11-13T13:25:03Z")

</div>

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

 ![New_branch_protection_rule](https://us1.discourse-cdn.com/flex015/uploads/travis_ci/original/1X/0baf07e260770e4fa92b3374b4ff66f840e3342b.png)

You can either

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

---

<div class="post-metadata">

**Author:** ![abitrolly](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/abitrolly/32/408_2.png) [@abitrolly](https://travis-ci.community/u/abitrolly)\
**Post date:** [November 14, 2018, 6:14am UTC](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829/3 "2018-11-14T06:14:05Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\
**Post date:** [November 14, 2018, 2:56pm UTC](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829/4 "2018-11-14T14:56:10Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![abitrolly](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/abitrolly/32/408_2.png) [@abitrolly](https://travis-ci.community/u/abitrolly)\
**Post date:** [November 15, 2018, 1:12pm UTC](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829/5 "2018-11-15T13:12:48Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\
**Post date:** [November 15, 2018, 2:14pm UTC](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829/6 "2018-11-15T14:14:09Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![abitrolly](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/abitrolly/32/408_2.png) [@abitrolly](https://travis-ci.community/u/abitrolly)\
**Post date:** [November 16, 2018, 6:44pm UTC](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829/7 "2018-11-16T18:44:35Z")

</div>

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`?

---

<div class="post-metadata">

**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\
**Post date:** [November 16, 2018, 11:51pm UTC](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829/8 "2018-11-16T23:51:38Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![abitrolly](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/abitrolly/32/408_2.png) [@abitrolly](https://travis-ci.community/u/abitrolly)\
**Post date:** [November 17, 2018, 9:15am UTC](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829/9 "2018-11-17T09:15:45Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\
**Post date:** [November 17, 2018, 11:49am UTC](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829/10 "2018-11-17T11:49:15Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![native-api](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/native-api/32/430_2.png) [@native-api](https://travis-ci.community/u/native-api)\
**Post date:** [November 17, 2018, 3:14pm UTC](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829/11 "2018-11-17T15:14:03Z")

</div>

> [@BanzaiMan](#):
>
> “PR build” is the merge commit upstream

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](http://www.bitsnbites.eu/a-tidy-linear-git-history/)”. 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.

---

<div class="post-metadata">

**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\
**Post date:** [November 17, 2018, 3:30pm UTC](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829/12 "2018-11-17T15:30:42Z")

</div>

> [@native-api](#):
>
> How can this be? A merge commit is only created after a branch – i.e. the PR – is merged.

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](https://travis-ci.com/Multy-io/Multy-back/builds/91361772#L345-L362) for what actually happens during the PR build.

---

<div class="post-metadata">

**Author:** ![abitrolly](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/abitrolly/32/408_2.png) [@abitrolly](https://travis-ci.community/u/abitrolly)\
**Post date:** [November 19, 2018, 6:45am UTC](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829/13 "2018-11-19T06:45:25Z")

</div>

> [@BanzaiMan](#):
>
> [https://travis-ci.com/Multy-io/Multy-back/builds/91361772#L345-L362](https://travis-ci.com/Multy-io/Multy-back/builds/91361772#L345-L362)

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.

---

<div class="post-metadata">

**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\
**Post date:** [November 19, 2018, 12:46pm UTC](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829/14 "2018-11-19T12:46:42Z")

</div>

> 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](https://travis-ci.community/t/travis-ci-branch-expected-waiting-for-status-to-be-reported/829/6)
