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

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.

3 Likes

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"))'

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.

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 https://travis-ci.org/yeputons/hse-2019-pb-tasks/builds/629655767
The PR #253 is checked instead of #25.

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.

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

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.

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

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?

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

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.

Imprint