feat(comment-commands): auto suggest reviewers on pr open/update via git blame

[juliethecao]

What changes were proposed in this PR?

This PR adds an automatic reviewer suggestion CI job to .github/workflows/comment-commands.yml. When a PR is opened or updated (pull_request: opened, synchronize, reopened), the CI automatically runs git blame -p at the base commit on each changed file to identify who most recently touched that code. Candidates are split into two groups:

• Committers — collaborators who can be formally review-requested via GitHub's API
• Non-committer contributors — have context but cannot be review-requested; the author can @-mention them to notify

The CI posts a comment in this format:
Suggested reviewers (based on git blame of changed files):
Committers — can be formally requested: @ alice, @ bob
Non-committer contributors — cc to notify: @ carol
Use /request-review @ alice to request a review, or cc @ carol to notify them.

On every subsequent push, the job finds the existing suggestion comment (via a hidden HTML marker ) and edits it in place, keeping the PR timeline clean. The CI never sends a review request on its own as the author must explicitly use /request-review @ user.

Files with status added are skipped before git blame is attempted since they did not exist at the base commit.

Any related issues, documentation, discussions?

Closes #5611

How was this PR tested?

Unit tests: 83 tests across 9 suites were written locally (https://github.com/juliethecao/texera/tree/cc-test) to cover the core JavaScript logic extracted from the workflow: git blame -p output parsing, candidate ranking, comment body generation, find-or-update marker logic, author/bot exclusion, @ mention parsing, file status filtering, candidate accumulation, and MARKER integrity. Tests were not checked in as the logic lives inside a GitHub Actions script rather than a standalone module.

Manual CI test: A test PR was opened on a personal fork (juliethecao#9) against the feature branch as the base. The suggest-reviewers job triggered on open, ran git blame on the changed files, and posted the suggestion comment. Closing and reopening the PR confirmed the comment was updated in place rather than duplicated.

Was this PR authored or co-authored using generative AI tooling?

Co-authored with Claude Sonnet 4.6 in compliance with ASF guidelines

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 52.80%. Comparing base (fa5fcbb) to head (0c808f3).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #5651      +/-   ##
============================================
- Coverage     52.96%   52.80%   -0.16%     
+ Complexity     2523     2513      -10     
============================================
  Files          1075     1075              
  Lines         41743    41743              
  Branches       4513     4513              
============================================
- Hits          22109    22043      -66     
- Misses        18330    18411      +81     
+ Partials       1304     1289      -15     

Flag	Coverage Δ		*Carryforward flag
access-control-service	71.42% <ø> (ø)
agent-service	34.36% <ø> (ø)
amber	53.34% <ø> (-0.41%)	⬇️
computing-unit-managing-service	1.65% <ø> (ø)
config-service	56.71% <ø> (ø)
file-service	57.06% <ø> (ø)
frontend	47.38% <ø> (ø)
pyamber	90.72% <ø> (ø)
python	90.74% <ø> (ø)		Carriedforward from 894fdab
workflow-compiling-service	58.69% <ø> (ø)

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

⚠️ Benchmark changes need a look

🟢 10 better · 🔴 2 worse · ⚪ 3 noise (<±5%) · 0 without baseline

CI benchmark results are noisy; treat <±5% as noise unless repeated.

Dashboard · Run

	config	throughput	MB/s	latency	max Δ latest / 7d
🔴	bs=10 sw=10 sl=64	405	0.247	22,603/36,963/36,963 us	🔴 +18.4% / 🟢 -7.3%
🟢	bs=100 sw=10 sl=64	992	0.606	102,309/113,846/113,846 us	🟢 -29.1% / 🟢 -19.2%
🟢	bs=1000 sw=10 sl=64	1,108	0.676	909,210/945,788/945,788 us	🟢 +16.9% / 🟢 +9.7%

Baseline details

Latest main 73c76f5 from 2026-06-12T22:35:57.354Z

config	metric	PR	latest main	7d avg	Δ latest	Δ 7d
bs=10 sw=10 sl=64	throughput	405 tuples/sec	420.77 tuples/sec	398.12 tuples/sec	-3.7%	+1.7%
bs=10 sw=10 sl=64	MB/s	0.247 MB/s	0.257 MB/s	0.243 MB/s	-3.8%	+1.6%
bs=10 sw=10 sl=64	p50	22,603 us	23,004 us	24,372 us	-1.7%	-7.3%
bs=10 sw=10 sl=64	p95	36,963 us	31,220 us	36,082 us	+18.4%	+2.4%
bs=10 sw=10 sl=64	p99	36,963 us	31,220 us	36,082 us	+18.4%	+2.4%
bs=100 sw=10 sl=64	throughput	992 tuples/sec	839.89 tuples/sec	870.8 tuples/sec	+18.1%	+13.9%
bs=100 sw=10 sl=64	MB/s	0.606 MB/s	0.513 MB/s	0.531 MB/s	+18.2%	+14.0%
bs=100 sw=10 sl=64	p50	102,309 us	119,184 us	114,334 us	-14.2%	-10.5%
bs=100 sw=10 sl=64	p95	113,846 us	160,656 us	140,980 us	-29.1%	-19.2%
bs=100 sw=10 sl=64	p99	113,846 us	160,656 us	140,980 us	-29.1%	-19.2%
bs=1000 sw=10 sl=64	throughput	1,108 tuples/sec	948.1 tuples/sec	1,010 tuples/sec	+16.9%	+9.7%
bs=1000 sw=10 sl=64	MB/s	0.676 MB/s	0.579 MB/s	0.617 MB/s	+16.8%	+9.6%
bs=1000 sw=10 sl=64	p50	909,210 us	1,048,503 us	994,062 us	-13.3%	-8.5%
bs=1000 sw=10 sl=64	p95	945,788 us	1,107,534 us	1,046,212 us	-14.6%	-9.6%
bs=1000 sw=10 sl=64	p99	945,788 us	1,107,534 us	1,046,212 us	-14.6%	-9.6%

Raw CSV

config_idx,batch_size,schema_width,string_len,num_batches,total_ms,total_tuples,total_bytes,tuples_per_sec,mb_per_sec,lat_p50_us,lat_p95_us,lat_p99_us
0,10,10,64,20,493.48,200,128000,405,0.247,22603.40,36962.83,36962.83
1,100,10,64,20,2015.45,2000,1280000,992,0.606,102308.80,113846.16,113846.16
2,1000,10,64,20,18057.56,20000,12800000,1108,0.676,909209.78,945788.34,945788.34

[Yicong-Huang]

I see on your fork run

Suggested reviewers (based on git blame of changed files):

Committers — none identified

No candidates found from blame history.

This is not ideal right? for a new file, there is no blame history. will it go to blame the parent folder or related file?

Could you test on three cases:

• adding a new file
• modifying a file
• deleting a file

To see the recommendations of each?

[juliethecao]

Case	Current behavior	Why
Adding a new file	git blame fails (caught), skips file → "No candidates found"	File didn't exist at base commit as there's nothing to blame
Modifying a file	git blame succeeds → suggests committers/non-committers	This is the primary intended use case
Deleting a file	Skipped entirely (status === 'removed') → "No candidates found"	File existed at base so blame is technically possible, but see note below

For all three test PRs, I used .github/welcome-first-time-contributor.txt as the test file to add it, modify it, and delete it respectively.

• Add case: test: add new file to test suggest-reviewers CI (add case) juliethecao/texera#10
• Modify case: test: modify existing file to test suggest-reviewers CI (modify case) juliethecao/texera#11
• Delete case: test: delete existing file to test suggest-reviewers CI (delete case) juliethecao/texera#12

Let me know if the modify case should use a more representative file (e.g. something with richer blame history across more contributors).

On the delete case: I currently skip deleted files, but since the file existed at the base commit, git blame would technically work. That said, I'm not sure it's the right call as whoever is deleting a file likely already knows what they're doing and is the most appropriate reviewer themselves. Happy to change the logic if you think surfacing blame candidates for deletions would be useful.