"pull_requests" when rerequest check run

截屏2020-09-09 下午4.12.24

I got inconsistent requests after clicking it on different PRs. Sometimes the request will include a “pull_requests” object but sometimes doesn’t.

I wonder what makes such differences and do we have any documents on the re-run for failed check run?

@XiongKezhi ,

Sometimes the request will include a “pull_requests” object but sometimes doesn’t.

Can you share an example to show the problem?
You can share your repository with us. Or share the example in an public repository, if your repository is private.

In addition, the problem seems is similar to the issue reported in the following earlier topic:

For example, if I rerun the failed check in this PR: https://github.com/jenkins-checks-api-test/codingstyle/pull/1/checks?check_run_id=1096912166, it will include the “pull_reuqest” object in the payload, but if I rerun this PR: https://github.com/jenkins-checks-api-test/codingstyle/pull/2/checks?check_run_id=1035758896, it doesn’t.

A request include “pull_request” would be like (see payload.check_run.pull_request, removed unrelated objects):


@XiongKezhi ,

Normally, when the Git ref (branch, commit SHA) of a check run is on the PR merge branch (refs/pull/:prNumber/merge), in the the payload of this check run, the “pull_requests” object should contains some information of the PR. Otherwise, the “pull_requests” object still is existing but empty (“pull_requests”:[ ]).

According to the payload of these two check runs, it seems that:

  1. For the first check run, the branch ref is the PR merge branch (refs/pull/1/merge), and the commit ref is the latest merge commit on the PR merge branch.

  2. For the second check run, the branch ref is the source branch (head branch) of the PR (code-coverage), and the the commit ref is the latest commit on source branch (b6b65cb).

In your case, due to the check runs are from the external services, we can’t see how you set the configurations to trigger these checks. If you set the same configurations for these checks, generally their payload should contain the consistent information.

In addition, I noticed you also setup some workflows with “pull_request” event in your repository, but I see no workflows were triggered to run on PR.