[BUG] Sometimes rerequested check_run events don't contain a PR list

The same app is installed into several orgs. In one test org when I click “Re-run” here https://github.com/sanitizers/browntruck/pull/1/checks?check_run_id=162132498 it has a non-empty list under check_run->check_suite->pull_requests. And for other orgs (namely, tox-dev and aio-libs) it’s empty when I click it @ https://github.com/aio-libs/aiohttp/pull/3804/checks?check_run_id=163078825, for example.

Broken:

{
"action":"rerequested",
"check\_run": {
    ...,
"output": {
"title":"Timeline protection: History fragments missing",
"summary":"Oops... This change does not have a record in the archives. Just as if it never happened!\n\n![Keeping chronicles is important](https://theeventchronicle.com/wp-content/uploads/2014/10/vatlib7.jpg)",
"text":"No files matching re.compile('CHANGES/(?P\<issue\_number\>[^\\\\./]+)\\\\.(?P\<fragment\_type\>bugfix|doc|feature|removal|trivial|vendor)(\\\\.\\\\d+)?(\\\\.[^\\\\./]+)\*$') pattern added",
"annotations\_count":0,
"annotations\_url":"https://api.github.com/repos/aio-libs/aiohttp/check-runs/163078825/annotations" },
"name":"Timeline protection",
"check\_suite": {
"id":157188790,
"node\_id":"MDEwOkNoZWNrU3VpdGUxNTcxODg3OTA=",
"head\_branch":null,
"head\_sha":"df644394d03c0076678f4ebc95c5d99d743ab3f2",
"status":"completed",
"conclusion":"failure",
"url":"https://api.github.com/repos/aio-libs/aiohttp/check-suites/157188790",
"before":null,
"after":null,
"pull\_requests": [

      ],
      ...,
"created\_at":"2019-07-06T16:45:49Z",
"updated\_at":"2019-07-06T16:45:50Z" },
    ...,
"pull\_requests": [

    ]
  },
  ...
}

Correct:

{
"action":"rerequested",
"check\_run": {
    ...,
"name":"Timeline protection",
"check\_suite": {
      ...,
"pull\_requests": [
        {
"url":"https://api.github.com/repos/sanitizers/browntruck/pulls/1",
"id":235276563,
"number":1,
"head": {
"ref":"feature/github-app-aiohttp",
"sha":"f2114ef3a920b908d091aaeb9377a119807f0380",
"repo": {
"id":160039456,
"url":"https://api.github.com/repos/sanitizers/browntruck",
"name":"browntruck" }
          },
"base": {
"ref":"master",
"sha":"6869c0bad05e74c5de5aaa6ff9f74e35b9626b6d",
"repo": {
"id":160039456,
"url":"https://api.github.com/repos/sanitizers/browntruck",
"name":"browntruck" }
          }
        }
      ],
      ...
    },
    ...,
"pull\_requests": [
      {
"url":"https://api.github.com/repos/sanitizers/browntruck/pulls/1",
"id":235276563,
"number":1,
"head": {
"ref":"feature/github-app-aiohttp",
"sha":"f2114ef3a920b908d091aaeb9377a119807f0380",
"repo": {
"id":160039456,
"url":"https://api.github.com/repos/sanitizers/browntruck",
"name":"browntruck" }
        },
"base": {
"ref":"master",
"sha":"6869c0bad05e74c5de5aaa6ff9f74e35b9626b6d",
"repo": {
"id":160039456,
"url":"https://api.github.com/repos/sanitizers/browntruck",
"name":"browntruck" }
        }
      }
    ]
  },
  ...
}
3 Likes

I have the same problem, even though this is documented behavior. I can’t quite work out how I would get this information. https://github.community/t5/GitHub-API-Development-and/API-v3-What-causes-a-check-run-suite-pull-request-field-to-be/m-p/23646

1 Like

If you’re having an issue consistently within specific orgs but not others, I would suspect that it is a permissions issue rather than a bug. It also appears that in the “broken” link that the branch being merged is from a forked repository whereas the successful one is being merged from within the repository itself. Can you confirm that this is consistently the case in the “broken” scenarios?

1 Like

This is an interesting suggestion. App privileges are the same. And also PRs from the same repo don’t have such problem.

It looks like the issue @ekohl linked above.

But it’s still weird that it works like this from the UX perspective:

This commit is in the same Git tree, even though it’s in a fork. GitHub can even display it under the upstream repo URL while “technically” not having it there: https://github.com/aio-libs/aiohttp/pull/3804/commits/a89226d9dc796bcad3b806c02d5cbd73e5f7539fhttps://github.com/aio-libs/aiohttp/commit/a89226d9dc796bcad3b806c02d5cbd73e5f7539f.

So GitHub is able to locate and show the commit as a part of the related Git tree. I think it’s quite expected that it’d also backtrack that in the webhook payload.

P.S. I know that PRs produce an ephemeral/artificial “merge commit”. If I post Check API updates against that commit, will the events contain the PRs list?

Same here. My webhook is getting a check_run event with the payload

{
  "action": "REQUESTED_ACTION",
  "check_run": {
    "head_sha": "74b075adcf9c6628dd66f0a5f45b122f001909dd",
    "pull_requests": [],
    ...
  },
  ...
}

I’ve verified that that commit hash matches the commit in the PR, so I’m confused why GitHub might be sending an empty array in check_run.pull_requests.

1 Like

It seems as well that head_branch is now set to null :

"name": "Tekton Pipeline as Code CI",
    "check_suite": {
      "id": 7,
      "node_id": "MDEwOkNoZWNrU3VpdGU3",
      "head_branch": null,
      "head_sha": "5e14aa1088e07fbccfc3c8ccd467af2120ace13c",
      "status": "in_progress",
      "conclusion": null,
      "url": "https://ghe.pipelines.devcluster.openshift.com/api/v3/repos/openshift-pipelines/pac-test/check-suites/7",
      "before": null,
      "after": null,
      "pull_requests": [

I am pretty sure it was set properly until end of june since my E2E was working properly by that time.

This seems to apply only on GHE, on public Github i am getting properly a head_branch and pull_requests filled,

ont his screenshot we have on the right the payload from public and on the left from GHE which has the the missing fields :

a workaround would be to query the /pulls from the repo via the api and match head.sha to check_run.check_suite.head_sha we will get all the infromation we need from there.

not very pretty and potential for troubles…

Facing this same issue. Will try @chmouel’s suggestion.

I have the same issue.
octokit/webhooks says

An array of pull requests that match this check suite. A pull request matches a check suite if they have the same head_sha and head_branch. When the check suite’s head_branch is in a forked repository it will be null and the pull_requests array will be empty.
webhooks/schema.d.ts at 378a8f3f5258d0189f07fabde5b947ab774eb6cc · octokit/webhooks · GitHub

If the repo is public, we can crawl the page https://github.com/<owner>/<repo>/actions/runs/<run_id> and search the pattern like data-hovercard-url="/<owner>/<repo>/pull/<want>/hovercard" or href="/<owner>/<repo>/pull/<want>".

But I want to know why can’t we get the number from API/Webhooks while we can get the number from web UI.