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

Travis CI Discussions & Feedback
,
1

Build: https://travis-ci.org/yeputons/hse-2019-pb-tasks/builds/616376488?utm_medium=notification&utm_source=github_status

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

$ git clone --depth=50 https://github.com/yeputons/hse-2019-pb-tasks.git 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.

2 Likes
2

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 https://api.github.com/repos/yeputons/hse-2019-pb-tasks/events. You can view it on Chrome, or run a simple query, if you know jq, for example:

    curl -sSfL https://api.github.com/repos/yeputons/hse-2019-pb-tasks/events | jq 'map(select(.type == "PullRequestEvent") | select(.payload.action == "reopened"))'
3

Thank you for reply!

I’ve tried closing and reopening a different PR with the same problem: https://github.com/yeputons/hse-2019-pb-tasks/pull/11
Corresponding build which was just triggered: https://travis-ci.org/yeputons/hse-2019-pb-tasks/builds/623808071
Logs still say $ git fetch origin +refs/pull/119/merge:

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

4

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

5

Here is an another example of this issue https://travis-ci.org/yeputons/hse-2019-pb-tasks/builds/629655767
The PR #253 is checked instead of #25.

6

Could someone push another commit to https://github.com/yeputons/hse-2019-pb-tasks/pull/25 and let me know as soon as possible so that I can examine the payload?

Thanks.

7

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

8

Here you go: https://github.com/yeputons/hse-2019-pb-tasks/pull/25/commits/c82c47ffd2aab6ea7e81f2d04e3d7885353fac5b

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

9

Payload displayed at https://github.com/yeputons/hse-2019-pb-tasks/settings/hooks: https://gist.github.com/yeputons/c275bc261e74048eb280c8c8ee98812a

10

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

$ curl -sSfL https://api.github.com/repos/yeputons/hse-2019-pb-tasks/events | jq 'map(.created_at)'
[
  "2020-01-03T09:30:32Z",
  "2020-01-03T09:29:49Z",
  "2019-12-31T22:09:27Z",
  "2019-12-30T04:22:03Z",
  "2019-12-30T04:11:01Z",
  "2019-12-30T04:08:10Z",
  "2019-12-29T23:25:36Z",
  "2019-12-29T23:25:33Z",
  "2019-12-29T20:34:42Z",
  "2019-12-29T20:00:15Z",
  "2019-12-29T20:26:27Z",
  "2019-12-29T20:26:02Z",
  "2019-12-29T20:19:13Z",
  "2019-12-29T19:58:47Z",
  "2019-12-29T19:56:17Z",
  "2019-12-29T19:57:44Z",
  "2019-12-29T19:58:34Z",
  "2019-12-29T19:50:40Z",
  "2019-12-29T19:49:48Z",
  "2019-12-29T19:48:15Z",
  "2019-12-13T14:47:34Z",
  "2019-12-13T14:49:30Z",
  "2019-12-29T19:40:58Z",
  "2019-12-29T19:39:16Z",
  "2019-12-29T19:37:42Z",
  "2019-12-29T19:28:39Z",
  "2019-12-29T19:30:52Z",
  "2019-12-29T19:29:29Z",
  "2019-12-28T09:38:33Z",
  "2019-12-23T23:31:09Z"
]

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

11

I will note that https://travis-ci.org/yeputons/hse-2019-pb-tasks/builds/635477758#L127 checks out the correct merge commit.

12

Sure, the webhook payload is available at https://gist.github.com/yeputons/c275bc261e74048eb280c8c8ee98812a .

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

13

I pushed some commits to a PR https://github.com/UCL/STIR/pull/44. However, the Travis jobs actually ran a commit from PR 449 https://github.com/UCL/STIR/pull/449 (which was then still open).

Here’s a link to one of the jobs https://travis-ci.org/UCL/STIR/jobs/657085845?utm_medium=notification&utm_source=github_status

Checking the log file for that job https://travis-ci.org/UCL/STIR/jobs/657290596#L1071 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?

14

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
15

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?

16

All right. I have a reproduction.

https://travis-ci.org/github/BanzaiMan/travis_production_test/builds/663233650#L187
https://travis-ci.org/github/BanzaiMan/travis_production_test/builds/663237225#L179

We’ll look into it.

1 Like
17

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

Problem

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.

Solution

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

https://travis-ci.org/github/BanzaiMan/travis_production_test/builds/664525177#L170 (PR 7, while PR 76 was still open.)

1 Like