You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Spackbot registers for check_run events and when it receives such a notification corresponding to a failed style check, it is supposed to post a comment to the PR suggesting how to fix the problem. This is not happening.
The problem seems to be that many (or possibly all) check_run events contain an empty list for pull_requests, which is used here to identify the PR where the helpful comment should be posted.
In this community discussion comment, someone has reported that the pull_requests field is only non-empty on the very first check_run event triggered for a PR, but the docs for that event seem to state that the pull_requests field will always be empty for a pull request where the head is on a fork. Either way it doesn't seem a reliable way to know the PR with which the check is associated.
Below is an example payload I captured recently. I don't see any direct way to link the check_run event to a pull request based on the data in this payload. However it appears we might be able to make another request at this point to list the prs associated with a commit and find, among the returned list of pull requests, the one matching the head_sha in the check_run.
Spackbot registers for
check_run
events and when it receives such a notification corresponding to a failed style check, it is supposed to post a comment to the PR suggesting how to fix the problem. This is not happening.The problem seems to be that many (or possibly all)
check_run
events contain an empty list forpull_requests
, which is used here to identify the PR where the helpful comment should be posted.In this community discussion comment, someone has reported that the
pull_requests
field is only non-empty on the very firstcheck_run
event triggered for a PR, but the docs for that event seem to state that thepull_requests
field will always be empty for a pull request where thehead
is on a fork. Either way it doesn't seem a reliable way to know the PR with which the check is associated.Below is an example payload I captured recently. I don't see any direct way to link the
check_run
event to a pull request based on the data in this payload. However it appears we might be able to make another request at this point to list the prs associated with a commit and find, among the returned list of pull requests, the one matching thehead_sha
in thecheck_run
.Example `check_run` payload
The text was updated successfully, but these errors were encountered: