Ma77Ball opened a new pull request, #5590:
URL: https://github.com/apache/texera/pull/5590
### What changes were proposed in this PR?
Adds a `Suggest reviewers` GitHub Actions workflow
(`.github/workflows/suggest-reviewers.yml`). When a PR is opened or
updated, it posts (and keeps updating) a single comment suggesting
reviewers, **without ever requesting a review automatically**.
Motivation: auto-requesting a reviewer can ping a past contributor who
no longer wants review requests (e.g. someone who touched a file years
ago and has moved on, with no way to opt out). This workflow only
*suggests*; the author stays in control of who actually gets pinged.
How it works:
- On `pull_request_target` (opened / reopened / synchronize /
ready_for_review), it ranks candidates from the recent commit history
of the changed files via `repos.listCommits` per file, which returns
the GitHub login directly (no unreliable git-email-to-login mapping).
The PR author and bots are excluded.
- It flags which candidates are **committers** (write/maintain/admin),
since GitHub only lets an author formally request review from
collaborators. Non-committers are still listed because they have
context, with a note to `cc` them instead.
- Every suggested login is rendered inside a code span (`` `@user` ``),
which GitHub does **not** turn into a notification. The suggestion
comment bothers nobody. Only the author's explicit `/request-review`
(handled by `comment-commands.yml`) or a manual `cc` actually reaches
out.
- The comment is idempotent via a hidden marker: subsequent PR updates
edit the same comment instead of posting new ones.
- Uses `pull_request_target` so fork PRs get a writable token, and it
never checks out or runs fork code (API-only).
Bounded API budget on large PRs: caps at 50 files, 30 commits/file, 6
suggestions.
Example rendered comment:
> ### Suggested reviewers
> Based on recent commit history of the files this PR changes (most relevant
first):
> - `@bob` (committer)
> - `@alice`
> - `@carol`
>
> **Author:** request a committer's review by commenting `/request-review
@bob` (trim or extend the list as you like).
>
> GitHub only lets you request review from committers. The non-committers
above know this code too: to loop them in for context, mention them in a normal
comment (e.g. `cc @alice @carol`).
### Any related issues, documentation, discussions?
Follows up on the discussion about not auto-sending review requests
(which prompted removing the "auto-assign a reviewer" wording from the
first-time-contributor welcome message). Complements the existing
`/request-review` command in `comment-commands.yml`.
Open question for reviewers: committer detection relies on
`getCollaboratorPermissionLevel`, which the default `GITHUB_TOKEN`
usually permits but may not in all configurations; the workflow degrades
gracefully (treats unknown as non-committer) on failure. If that proves
unreliable, alternatives are a checked-in committers list or a
`CODEOWNERS` file (the repo has neither today).
### How was this PR tested?
This is a workflow-only change. Validated statically:
- YAML parses cleanly (`yaml.safe_load`).
- The embedded `github-script` JS passes `node --check` (wrapped in an
async function, matching how `actions/github-script` executes it).
Full end-to-end behavior (comment content, committer flagging, idempotent
update) is exercised by GitHub Actions on real PR events once the
workflow is on the default branch, since `pull_request_target` workflows
run from the base branch. Happy to validate on a scratch PR if preferred.
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Claude Opus 4.8)
--
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]
