spuru9 commented on code in PR #28341:
URL: https://github.com/apache/flink/pull/28341#discussion_r3706837724
##########
.github/workflows/community-review.sh:
##########
@@ -247,11 +253,13 @@ process_target_branch_label() {
# $1 - GitHub API token for authentication
# $2 - PR number
# $3 - PR reviews
+# $4 - PR author login (excluded from the review tally)
Review Comment:
Done — co-authors are now excluded too, in 321bd44.
One wrinkle worth flagging, because it changed the shape of the fix. GitHub
credits a reviewer as co-author the moment the author presses *Commit
suggestion*, so co-authorship is sometimes a product of the review rather than
something that predates it. Across the 330 open non-draft PRs there are exactly
two reviewers who are also commit co-authors, #28791 and #28793, and both are
that case. On #28791:
```
07-21 16:30 0b21c6ef pushed by the PR author
07-27 06:58 raminqaf leaves five reviews carrying suggestions
07-27 16:01 2f7431ad "Update .../CatalogManager.java", committer web-flow,
Co-authored-by: Ramin Gharib
```
A flat co-author exclusion would have stripped the label from exactly the
reviews it is meant to showcase. So a reviewer is skipped only when they had
already authored a commit on the PR before their first review; co-authorship
that shows up afterwards still counts. One known gap, written up in the
description: squashing a suggestion commit into an earlier one rewinds the
author date and defeats the check. Using `committedDate` instead trades it for
a worse failure, since rebasing rewrites that for genuine co-authors too.
You were right that "it is rare" was not the answer — chasing it turned up
that the tally was also dropping a co-author's request for changes, which is
now counted whoever it came from.
The lookup needs a commits query per PR, so 25f1cf1 pays for it: PR labels
now come from the open-PRs query the script already pages through rather than a
REST call per PR (`call_github_get_labels_api` is gone), and the lookup is
skipped where it cannot change the outcome. End to end over all 370 open PRs
that is 36 GraphQL calls and no REST label calls, against roughly 4 GraphQL and
185 REST before — fewer calls than the script made before any of this.
Separately, and not touched here: the draft filter at line 124 uses
`select((.node.isDraft = false))` — a jq assignment, not a comparison — so it
retains every PR and drafts are processed. The log gives it away, every page
reports "100 PR retained" out of 100. Happy to fix in this PR or a follow-up,
whichever you prefer.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
