Conversation
|
Note
|
| Cohort / File(s) | Summary |
|---|---|
Pull Request Template .github/pull_request_template.md |
New PR template with sections for describing changes, explaining necessity, and a validation checklist. |
GitHub Actions Workflows .github/workflows/peer-review-reminder.yml, .github/workflows/pr-title-format-check.yml |
Two new automation workflows: one that posts/removes peer review reminders based on PR approval status, another that validates PR titles match required prefixes (fix:, feat:, docs:, add:, update:). |
Estimated code review effort
🎯 2 (Simple) | ⏱️ ~15 minutes
🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
| Check name | Status | Explanation |
|---|---|---|
| Description Check | ✅ Passed | Check skipped - CodeRabbit’s high-level summary is enabled. |
| Title check | ✅ Passed | The title 'add: workflows' directly aligns with the primary changes: adding three new workflow files (.github/workflows/peer-review-reminder.yml, .github/workflows/pr-title-format-check.yml) and a PR template. |
| Docstring Coverage | ✅ Passed | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. |
✏️ Tip: You can configure your own custom pre-merge checks in the settings.
✨ Finishing Touches
🧪 Generate unit tests (beta)
- Create PR with unit tests
- Post copyable unit tests in a comment
📝 Coding Plan
- Generate coding plan for human review comments
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands and usage tips.
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/pull_request_template.md:
- Around line 1-11: Change the first heading "## What does this PR change?" to a
top-level heading "# What does this PR change?", add a blank line immediately
after the "## Checklist" heading to satisfy markdownlint's required blank line
after headings, and ensure the file ends with exactly one trailing newline;
update the headings and trailing-newline in the .github/pull_request_template.md
content (look for the "What does this PR change?", "Why is this needed?", and
"## Checklist" lines) to apply these fixes.
In @.github/workflows/peer-review-reminder.yml:
- Around line 46-50: The current calls using github.rest.pulls.listReviews and
github.rest.issues.listComments destructure a single page ({ data: reviews } / {
data: comments }) and will miss items beyond the first page; replace both with
github.paginate(...) to fetch all pages for reviews and comments (use
github.paginate(github.rest.pulls.listReviews, { owner: repo.owner, repo:
repo.repo, pull_number: prNumber }) and
github.paginate(github.rest.issues.listComments, { owner: repo.owner, repo:
repo.repo, issue_number: prNumber })) and assign their full arrays to the
existing reviews and comments variables so the reminder logic uses complete
datasets and avoids duplicate or false reminders.
- Around line 53-55: The current logic uses reviews.find(...) to locate an
'APPROVED' review which can pick an outdated approval; instead, iterate the
reviews sorted by submitted_at and build a Map keyed by review.user.login
storing each reviewer’s latest review.state, then check that deduplicated map
for any reviewer (excluding pr.user.login) whose final state is 'APPROVED' to
decide approval; update the code around the reviews variable and the
approvedReview lookup (replace the find usage) to perform sorting by
submitted_at, populating the Map, and checking the Map for final approvals.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: alphaonelabs/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 152f423a-9313-45a6-ba93-de70ae45886c
📒 Files selected for processing (3)
.github/pull_request_template.md.github/workflows/peer-review-reminder.yml.github/workflows/pr-title-format-check.yml
| ## What does this PR change? | ||
| <!-- Briefly describe your changes --> | ||
|
|
||
| ## Why is this needed? | ||
| <!-- Explain the motivation or issue --> | ||
|
|
||
| ## Checklist | ||
| - [ ] Code runs locally | ||
| - [ ] Tests pass | ||
| - [ ] No hardcoded secrets | ||
| - [ ] Documentation updated No newline at end of file |
There was a problem hiding this comment.
Fix markdownlint violations in the PR template.
Line 1 should be a top-level heading, Line 7 should have a blank line after it, and the file should end with a single trailing newline.
💡 Suggested patch
-## What does this PR change?
+# What does this PR change?
<!-- Briefly describe your changes -->
## Why is this needed?
<!-- Explain the motivation or issue -->
## Checklist
+
- [ ] Code runs locally
- [ ] Tests pass
- [ ] No hardcoded secrets
- [ ] Documentation updated🧰 Tools
🪛 markdownlint-cli2 (0.21.0)
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
[warning] 7-7: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 11-11: Files should end with a single newline character
(MD047, single-trailing-newline)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/pull_request_template.md around lines 1 - 11, Change the first
heading "## What does this PR change?" to a top-level heading "# What does this
PR change?", add a blank line immediately after the "## Checklist" heading to
satisfy markdownlint's required blank line after headings, and ensure the file
ends with exactly one trailing newline; update the headings and trailing-newline
in the .github/pull_request_template.md content (look for the "What does this PR
change?", "Why is this needed?", and "## Checklist" lines) to apply these fixes.
| const { data: reviews } = await github.rest.pulls.listReviews({ | ||
| owner: repo.owner, | ||
| repo: repo.repo, | ||
| pull_number: prNumber, | ||
| }); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/peer-review-reminder.ymlRepository: alphaonelabs/scholarai
Length of output: 5167
🌐 Web query:
GitHub API listReviews default page size pagination
💡 Result:
For the REST endpoint “List reviews for a pull request” (GET /repos/{owner}/{repo}/pulls/{pull_number}/reviews):
- Default page size:
per_page=30(max100) [1] - Default page:
page=1[1] - Pagination: request additional pages via
?page=N(and optionallyper_page=...), or follow the responseLinkheader (rel="next",rel="last", etc.) [2]
Example:
GET /repos/OWNER/REPO/pulls/123/reviews?per_page=100&page=2Sources: [1] [2]
🌐 Web query:
@actions/github-script paginate function available v7
💡 Result:
Yes. In actions/github-script@v7, the Octokit pagination helper is still available as github.paginate (it’s explicitly noted as unchanged). (github.com)
Example:
- uses: actions/github-script@v7
with:
script: |
const issues = await github.paginate(
github.rest.issues.listForRepo,
{ owner: context.repo.owner, repo: context.repo.repo, state: "open", per_page: 100 }
)
core.info(`Fetched ${issues.length} issues`)Citations:
Paginate reviews and comments to avoid false reminders on busy PRs.
The GitHub API defaults to 30 items per page for both listReviews and listComments endpoints. On PRs with more than 30 reviews or comments, the script may miss approvals on later pages (posting false reminders) or fail to detect previous reminder comments (posting duplicates).
Replace the destructured calls with github.paginate() at lines 46–50 and 61–65:
💡 Suggested patch
- const { data: reviews } = await github.rest.pulls.listReviews({
- owner: repo.owner,
- repo: repo.repo,
- pull_number: prNumber,
- });
+ const reviews = await github.paginate(github.rest.pulls.listReviews, {
+ owner: repo.owner,
+ repo: repo.repo,
+ pull_number: prNumber,
+ per_page: 100,
+ });
...
- const { data: comments } = await github.rest.issues.listComments({
- owner: repo.owner,
- repo: repo.repo,
- issue_number: prNumber,
- });
+ const comments = await github.paginate(github.rest.issues.listComments, {
+ owner: repo.owner,
+ repo: repo.repo,
+ issue_number: prNumber,
+ per_page: 100,
+ });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/peer-review-reminder.yml around lines 46 - 50, The current
calls using github.rest.pulls.listReviews and github.rest.issues.listComments
destructure a single page ({ data: reviews } / { data: comments }) and will miss
items beyond the first page; replace both with github.paginate(...) to fetch all
pages for reviews and comments (use
github.paginate(github.rest.pulls.listReviews, { owner: repo.owner, repo:
repo.repo, pull_number: prNumber }) and
github.paginate(github.rest.issues.listComments, { owner: repo.owner, repo:
repo.repo, issue_number: prNumber })) and assign their full arrays to the
existing reviews and comments variables so the reminder logic uses complete
datasets and avoids duplicate or false reminders.
| const approvedReview = reviews.find( | ||
| review => review.state === 'APPROVED' && review.user.login !== pr.user.login | ||
| ); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/peer-review-reminder.ymlRepository: alphaonelabs/scholarai
Length of output: 5167
🌐 Web query:
GitHub REST API pulls listReviews multiple reviews same user documentation
💡 Result:
GET /repos/{owner}/{repo}/pulls/{pull_number}/reviews returns all review submissions, in chronological order, not a deduplicated “one review per user” list—so it’s normal to see multiple entries from the same user if they reviewed more than once (e.g., “CHANGES_REQUESTED” then later “APPROVED”). [1]
If you need “latest review per user”, you have to post-process the list (group by user.login, take the one with the greatest submitted_at / last in the array). If you specifically need the latest review by a specific user more efficiently, GitHub’s GraphQL API supports querying PR reviews filtered by author and limited to last: 1. [2]
Sources: [1] GitHub REST docs – Pull request reviews (“List reviews… returns in chronological order”) ; [2] GitHub Community discussion with GraphQL approach for “latest review by user”.
Track each reviewer's latest state instead of matching the first approval.
The GitHub API's listReviews endpoint returns all historical reviews in chronological order, including multiple entries per reviewer. When using find() to match the first APPROVED review, the code may select an outdated approval even if that reviewer later requested changes or dismissed their review. This causes the reminder to be incorrectly removed or skipped.
Build a Map of the latest review state per reviewer by processing reviews sorted by submitted_at, then check for approval in that deduplicated set.
💡 Suggested patch
- const approvedReview = reviews.find(
- review => review.state === 'APPROVED' && review.user.login !== pr.user.login
- );
+ const latestReviewStateByUser = new Map();
+ for (const review of reviews.sort(
+ (a, b) => new Date(a.submitted_at) - new Date(b.submitted_at)
+ )) {
+ const reviewer = review.user?.login;
+ if (!reviewer || reviewer === pr.user.login) continue;
+ latestReviewStateByUser.set(reviewer, review.state);
+ }
+ const approvedReviewer = [...latestReviewStateByUser.entries()]
+ .find(([, state]) => state === 'APPROVED')?.[0];
- if (approvedReview) {
- console.log(`PR #${prNumber} has an approved review from ${approvedReview.user.login}`);
+ if (approvedReviewer) {
+ console.log(`PR #${prNumber} has an approved review from ${approvedReviewer}`);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const approvedReview = reviews.find( | |
| review => review.state === 'APPROVED' && review.user.login !== pr.user.login | |
| ); | |
| const latestReviewStateByUser = new Map(); | |
| for (const review of reviews.sort( | |
| (a, b) => new Date(a.submitted_at) - new Date(b.submitted_at) | |
| )) { | |
| const reviewer = review.user?.login; | |
| if (!reviewer || reviewer === pr.user.login) continue; | |
| latestReviewStateByUser.set(reviewer, review.state); | |
| } | |
| const approvedReviewer = [...latestReviewStateByUser.entries()] | |
| .find(([, state]) => state === 'APPROVED')?.[0]; | |
| if (approvedReviewer) { | |
| console.log(`PR #${prNumber} has an approved review from ${approvedReviewer}`); |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/peer-review-reminder.yml around lines 53 - 55, The current
logic uses reviews.find(...) to locate an 'APPROVED' review which can pick an
outdated approval; instead, iterate the reviews sorted by submitted_at and build
a Map keyed by review.user.login storing each reviewer’s latest review.state,
then check that deduplicated map for any reviewer (excluding pr.user.login)
whose final state is 'APPROVED' to decide approval; update the code around the
reviews variable and the approvedReview lookup (replace the find usage) to
perform sorting by submitted_at, populating the Map, and checking the Map for
final approvals.
Summary
This PR introduces GitHub Actions workflows and a standardized PR template to improve development workflow and code review processes.
Changes
Pull Request Template (
.github/pull_request_template.md)Peer Review Reminder Workflow (
.github/workflows/peer-review-reminder.yml)copilot/branchPR Title Format Validation Workflow (
.github/workflows/pr-title-format-check.yml)fix:,feat:,docs:,add:, orupdate:(case-insensitive)Impact
These additions establish automated governance for PRs by enforcing naming conventions and encouraging code review discipline, while the template ensures consistent documentation across the project.