[FLINK-40320][ci] Exclude author and co-author reviews from community review labeling by spuru9 · Pull Request #28341 · apache/flink

spuru9 · 2026-06-06T17:00:36Z

What is the purpose of the change

community-review.sh applies the community-reviewed label when a non-committer reviews a PR, but the tally also counted reviews written by the people who wrote the PR — the author, and any co-author. Neither is a community review. #28190 is a live example: its only reviews are two COMMENTED reviews by its own author, and it carries the label.

Co-authors need care, though. GitHub adds Co-authored-by: <reviewer> as soon as the author presses Commit suggestion, so co-authorship is often produced by the review itself — both such cases in the repo today (#28791, #28793) are that. Excluding co-authors outright would drop the label from exactly the reviews it exists to showcase, so a reviewer is skipped only when they had already authored a commit before their first review.

Known gap: squashing a suggestion commit into an earlier one rewinds the author date and defeats that check. Comparing committedDate instead would be worse, since rebasing rewrites it for genuine co-authors too.

Brief change log

Skip reviews by the PR author, and by co-authors whose commits predate their first review
Count a request for changes whoever it came from — unlike the author, a co-author can submit one
Read PR labels from the open-PRs query rather than a REST call per PR, retiring call_github_get_labels_api

Verifying this change

This change reworks the community review labeling script and has no production code impact.

Covered by running the script's functions with the GitHub calls mocked: author-only review, suggestion-generated co-author (still counted), co-author who contributed first (not counted), co-author's request for changes still blocking LGTM, committer approval still suppressing LGTM, and a GraphQL failure aborting rather than silently counting everyone.

Also run end to end against the live repository with only label mutations and the permission lookup stubbed. All 370 open PRs processed, decisions matching the labels currently on them, at ~180 GraphQL calls and 143 REST calls, against ~4 GraphQL and ~507 REST before this change.

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? not applicable

Was generative AI tooling used to co-author this PR?

Yes (Claude Code)

Generated-by: Claude Code

…ew labeling The community review GitHub Action applies the `community-reviewed` label when a non-committer reviews a PR. It also counted the PR author's own reviews (for example, a self-comment on their own PR) as a community review, so a PR could be labeled `community-reviewed` purely because its author commented on it, with no actual community review having occurred. Fetch the PR author login in the open-PRs query, pass it into the review tally, and skip reviews authored by the PR author so that only reviews from other community members are counted.

flinkbot · 2026-06-06T17:04:53Z

CI report:

0513e2c Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

@flinkbot run azure re-run the last Azure build

spuru9 · 2026-08-03T17:04:52Z

@ferenc-csaky @snuyanzin Can you take a look.

The situation I am trying to tackle in something like in #28895
No review from community but is marked with label

snuyanzin · 2026-08-03T17:21:36Z

 #   $1 - GitHub API token for authentication
 #   $2 - PR number
 #   $3 - PR reviews
+#   $4 - PR author login (excluded from the review tally)


what about co-authors?

I can take a look at that. I didn't see a co-author case happening much in PRs.

I didn't see a co-author case happening much in PRs.

!= 0%
and anyway you are touching this code

Have added the co-author part as well. As this increases the number of call, have tried to optimise call.
Have intentionally kept separate commits for easy review, please squash and merge when final.
Have created a JIRA as the scope is a little bigger.

…w labeling A review left by someone who worked on the PR is no more a community review than one left by the PR author, but the tally counted it, so a PR could be labeled `community-reviewed` off the back of its own contributors. Co-authorship on its own is not enough to disqualify a reviewer, though. GitHub records a reviewer as co-author the moment the PR author commits one of their suggestions, so the two cases in the repo today (apache#28791, apache#28793) are reviewers who earned their co-authorship by reviewing. Excluding them would drop the label from exactly the reviews it is meant to showcase. Skip a reviewer only when they had already authored a commit on the PR before their first review. The co-authors are fetched per PR, and only once a review would otherwise be counted, so the extra query is paid only for PRs that have a community reviewer. A request for changes is now counted whoever it came from, since a co-author, unlike the author, can submit one. Generated-by: Claude Code (claude-opus-5)

snuyanzin · 2026-08-03T19:03:21Z

+      printf "%-15s | %-20s | %-20s - checking user permissions..." "$user" "$state" "$time"
+      push_permission=$(call_github_get_user_push_permission "$token" "$user") || exit
+      printf "%s\n" "$push_permission"
+
+      #see if the user has read role
+      if [[ "$push_permission" == "true" ]]; then
+        if [[ "$state" == "APPROVED" ]]; then
+          ((++committerApproves))
+        fi
+      else
+        # only worth paying for the co-author lookup once a review would otherwise be counted
+        if [[ "$coauthor_lookup_needed" == "true" && -z "${pr_coauthors+set}" ]]; then
+          pr_coauthors="$(get_pr_coauthors "$token" "$pr_number")" || exit
+        fi
+        if is_coauthor_before_review "$user" "$first_review_time" "${pr_coauthors-}"; then
+          printf "%-15s | %-20s | %-20s - skipping PR co-author self-review\n" "$user" "$state" "$time"
+        else
+          ((++communityReviews))
+          if [[ "$state" == "APPROVED" ]]; then
+            ((++communityApproves))
+          fi
+        fi


what it is about and why do we need it?

is_coauthor_before_review skips a reviewer who wrote part of the PR before reviewing it, since they aren't reviewing it as a community member.
This is to tackle the situation in which you provide suggestion, when the author accept the suggestion you get added as coauthor, but you were a review at that point.

and what will change?
will it just drop the label or what?
Initially I had impression the PR is only about label handling
however it looks like it is getting a way more complicated

It doesnt drop label. If X first add a review and then become a co-author it is community-reviewed else if he already is a co-author he cant be a reviewer. (This is specifically for the suggestion part)

Yup adding co-author adds a little complexity.

it still doesn't answer why we need to look at permissions here.

My impression was: having a very dummy method: get all coathors + author, get all reviewers, find the diff, if diff == 0 then no label should be put.

Why are we looking at permissions, APPROVE and something else?

I think there is some confusion here, If you are talking about this block

printf "%-15s | %-20s | %-20s - checking user permissions..." "$user" "$state" "$time" push_permission=$(call_github_get_user_push_permission "$token" "$user") || exit printf "%s\n" "$push_permission" #see if the user has read role if [[ "$push_permission" == "true" ]]; then if [[ "$state" == "APPROVED" ]]; then ((++committerApproves)) fi

This is just being rearranged in this PR. Its already there in the original code. They are just being indented. (See 268-276 in main, FLIP-518)

The only part I have added in to check the coauthor_lookup_needed and is_coauthor_before_review.

The script asked GitHub for a PR's existing labels over REST, once for every PR about to be labeled and again for every PR targeting a release branch. The open-PRs query it already pages through can carry them instead, at no extra cost. Read them there, pass them down, and retire `call_github_get_labels_api`. Against the 370 open PRs this takes the REST calls a run makes from ~507 down to ~143. Generated-by: Claude Code (claude-opus-5)

snuyanzin reviewed Aug 3, 2026

View reviewed changes

spuru9 changed the title ~~[hotfix][ci] Exclude PR author's own reviews from community review labeling~~ [hotfix][ci] Exclude author and co-author reviews from community review labeling Aug 3, 2026

spuru9 changed the title ~~[hotfix][ci] Exclude author and co-author reviews from community review labeling~~ [FLINK-40320][ci] Exclude author and co-author reviews from community review labeling Aug 3, 2026

snuyanzin reviewed Aug 3, 2026

View reviewed changes

Comment thread .github/workflows/community-review.sh Outdated

spuru9 force-pushed the hotfix/community-review-exclude-author branch from 25f1cf1 to bbb283f Compare August 3, 2026 19:05

spuru9 force-pushed the hotfix/community-review-exclude-author branch from bbb283f to 0513e2c Compare August 4, 2026 04:30

spuru9 requested a review from snuyanzin August 4, 2026 17:37

Navigation Menu

Uh oh!

[FLINK-40320][ci] Exclude author and co-author reviews from community review labeling - #28341

[FLINK-40320][ci] Exclude author and co-author reviews from community review labeling#28341
spuru9 wants to merge 3 commits into
apache:masterfrom
spuru9:hotfix/community-review-exclude-author

spuru9 commented Jun 6, 2026 •

edited

Loading

Uh oh!

flinkbot commented Jun 6, 2026 •

edited

Loading

Uh oh!

spuru9 commented Aug 3, 2026 •

edited

Loading

Uh oh!

snuyanzin Aug 3, 2026

Uh oh!

spuru9 Aug 3, 2026

Uh oh!

snuyanzin Aug 3, 2026

Uh oh!

spuru9 Aug 3, 2026

Uh oh!

snuyanzin Aug 3, 2026

Uh oh!

spuru9 Aug 3, 2026

Uh oh!

snuyanzin Aug 3, 2026

Uh oh!

spuru9 Aug 3, 2026

Uh oh!

snuyanzin Aug 3, 2026

Uh oh!

spuru9 Aug 4, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

spuru9 commented Jun 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is the purpose of the change

Brief change log

Verifying this change

Does this pull request potentially affect one of the following parts:

Documentation

Was generative AI tooling used to co-author this PR?

Uh oh!

flinkbot commented Jun 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

CI report:

Uh oh!

spuru9 commented Aug 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

spuru9 Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

spuru9 commented Jun 6, 2026 •

edited

Loading

flinkbot commented Jun 6, 2026 •

edited

Loading

spuru9 commented Aug 3, 2026 •

edited

Loading

spuru9 Aug 4, 2026 •

edited

Loading