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.

I pushed some commits to a PR However, the Travis jobs actually ran a commit from PR 449 (which was then still open).

Here’s a link to one of the jobs

Checking the log file for that job says

  • branch refs/pull/449/merge -> FETCH_HEAD

which clearly should have been:

  • branch refs/pull/44/merge -> FETCH_HEAD

This looks like a Travis bug?

Looks like Travis is picking up the latest wildcard-matched refs/pull/${TRAVIS_PULL_REQUEST}* rather than refs/pull/${TRAVIS_PULL_REQUEST}/merge

1 Like

It seems that way. The trouble is that, although we’ve had reports, we have been unable to reproduce it.

What happens if you push a new commit to this PR?

All right. I have a reproduction.

We’ll look into it.

1 Like

We’ve deployed a fix to this issue. To summarize:


When there are multiple open PRs for a repository where one matches the prefix of another (e.g., 7 & 79, 44 & 443), if a new PR build is triggered on the shorter/older PR, the merge commit from the newest one is checked out instead.


We’ve fixed the bug. If you saw the problem earlier, please push a new commit to the old PR. This should result in checking out the correct merge commit.

See (PR 7, while PR 76 was still open.)

1 Like