Build checks out wrong Pull Request: #79 instead of #7?


On the top it says: “Pull Request #7” and “Commit 36384f8”. However, logs say:

$ git clone --depth=50 yeputons/hse-2019-pb-tasks
$ cd yeputons/hse-2019-pb-tasks
$ git fetch origin +refs/pull/79/merge:

Note that it pulls Pull Request #79 instead of #7 for whatever reason. Consequently, it takes commit from the wrong pull request (36384f8 is a merge commit for 6ad824 for #79, no relation to #7 whatsoever).

This causes wrong status reporting for at least one PRs.

Any ideas on how to fix/work around this issue and make Travis report correct status? What can/should I fix to avoid such issue in the future?

UPD: I’ve tried closing and re-opening the PR to trigger a new job, it happened, but same thing happens: Travis pulls refs/pull/79/merge instead of refs/pull/7/merge.

This question was also posted at StackOverflow.


I looked at various data, and the only explanation I’ve come up with is that 79 was the reference we got when we configured the PR build. Unfortunately, GitHub makes available only 300 events for a repository, and the event we are interested in from 17 days ago is no longer available at this moment.

I’ve tested, and confirmed that closing and re-opening a PR sends new events, so in theory, we should be able to confirm the payload. To do this:

  1. Close the PR in question if it’s not already.

  2. Re-open the PR

  3. Inspect the newly generated PullRequestEvent from You can view it on Chrome, or run a simple query, if you know jq, for example:

    curl -sSfL | jq 'map(select(.type == "PullRequestEvent") | select(.payload.action == "reopened"))'

Thank you for reply!

I’ve tried closing and reopening a different PR with the same problem:
Corresponding build which was just triggered:
Logs still say $ git fetch origin +refs/pull/119/merge:

Corresponding GitHub payloads for closing and reopening the PR are available at for your inspection. It does not have “119” as a substring, “11” only.

Thanks for the extra effort here. Very much appreciated. It does appear that the payload from GitHub is correct.

Here is an another example of this issue
The PR #253 is checked instead of #25.

Could someone push another commit to and let me know as soon as possible so that I can examine the payload?


Also, has anyone seen this issue other than this repository?

Here you go:

I have not used Travis CI extensively before, so I did not see this issue with other repositories.

Payload displayed at

Hmm. I don’t see these events for some reason:

$ curl -sSfL | jq 'map(.created_at)'

Since I can’t see the payload, could you paste it here?

I will note that checks out the correct merge commit.

Sure, the webhook payload is available at .

I suspect that pushing another commit “fixes” the issue, while closing and reopening does not, as it happened above with PR 11.