Wrong `head_branch` in a forked repo's check-suite

In the documentation:


it is explicitly said that

When the check suite’s head_branch is in a forked repository it will be null and the pull_requests array will be empty.

However that does not appear to be true! More specifically the head_branch is not null - it is being set to the forked repo’s branch name. Notice both the API and webhook event payload have it wrong.

For example see https://github.com/MicroShed/microshed-testing/actions/runs/309050388

@ivailop,

From the example link you shared, we do not find any check runs and check suites that were created via the Checks API. All of the displayed jobs in the workflow run are normal.

The limitation about the Checks API is applied to that when you use GitHub Apps to run the Checks API. When triggering a workflow from a forked repository, the limitation is not applied to the jobs in the workflow.

The limitation about the Checks API is applied to that when you use GitHub Apps to run the Checks API. When triggering a workflow from a forked repository, the limitation is not applied to the jobs in the workflow.

Shouldn’t that be clearly explained in the documentation?

@ivailop,

I think you may have some misunderstandings for checks on a PR.
The checks on a PR can be the following:

  1. Jobs in the workflows triggered by the events related to pull request.

    These jobs are generated via the GitHub build-in GitHub Actions app, not the integrated 3rd-party GitHub Apps.

  2. Checks generated from the integrated 3rd-party GitHub Apps.

    • Pipeline runs or jobs from the integrated 3rd-party CI/CD services, such Azure Pipelines.
    • Check runs generated by the integrated 3rd-party GitHub Apps via the Checks API.

To view more details about Checks API, I recommend you to see “Getting started with the Checks API”.