Currently the action posts each inline comment as an independent API call, resulting in multiple separate comment notifications on a PR. GitHub provides a dedicated Pull Request Reviews API designed specifically for this use case — it lets a reviewer stage multiple inline comments and submit them together as a single review event with an overall status (COMMENT, APPROVE, or REQUEST_CHANGES).
Requested behavior:
Add an input (e.g. use_pr_review) that, when enabled, collects all inline comments and submits them together via POST /repos/{owner}/{repo}/pulls/{pull_number}/reviews rather than posting each as an individual comment.
Why this matters:
- Reduces notification noise — PR authors currently get one notification per comment rather than one for the entire review
- Produces a cohesive review that appears in GitHub's "Reviews" section of the PR timeline, matching the experience of a human reviewer
- Allows an overall review verdict to accompany the inline feedback
- Avoids cluttering the PR comment thread with many independent entries
Related:
use_sticky_comment addresses a similar concern for top-level comments but doesn't apply to inline code comments, and doesn't use the GitHub review submission model.
Currently the action posts each inline comment as an independent API call, resulting in multiple separate comment notifications on a PR. GitHub provides a dedicated
Pull Request Reviews APIdesigned specifically for this use case — it lets a reviewer stage multiple inline comments and submit them together as a single review event with an overall status (COMMENT,APPROVE, orREQUEST_CHANGES).Requested behavior:
Add an input (e.g.
use_pr_review) that, when enabled, collects all inline comments and submits them together viaPOST /repos/{owner}/{repo}/pulls/{pull_number}/reviewsrather than posting each as an individual comment.Why this matters:
Related:
use_sticky_commentaddresses a similar concern for top-level comments but doesn't apply to inline code comments, and doesn't use the GitHub review submission model.