GH-51199: [CI] Limit concurrent PRs from new contributors - #51200
GH-51199: [CI] Limit concurrent PRs from new contributors#51200thisisnic wants to merge 4 commits into
Conversation
|
I tested it here on my fork with a temporary limit of 1 and it appears to be working: thisisnic#35 |
There was a problem hiding this comment.
🟡 Changes recommended
The new workflow is missing required token permissions for checkout and the auto-comment contains a broken PR-list link (plus a likely comment-spam edge case on repeated reopens).
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Adds a GitHub Actions guardrail to automatically close newly opened/reopened PRs from contributors without write access when they exceed a concurrent open-PR limit, and documents the policy in the contributor guidelines.
Changes:
- Introduces a
pull_request_targetworkflow (PR Limit) that counts a non-writer’s open PRs and auto-closes PRs that exceedPR_LIMIT. - Adds an automated explanatory comment template for closed PRs.
- Documents the “max 3 concurrent open PRs” policy in the developer bug report / contribution guidance docs.
File summaries
| File | Description |
|---|---|
| docs/source/developers/bug_reports.rst | Documents the concurrent PR limit policy for contributors without write access. |
| .github/workflows/pr_limit/comment.md | Adds the canned comment posted when a PR is auto-closed for exceeding the limit. |
| .github/workflows/pr_limit/check.js | Implements the permission check, open-PR counting, and comment+close behavior. |
| .github/workflows/pr_limit.yml | Adds the workflow wiring (trigger, permissions, checkout main, run github-script). |
Review details
- Files reviewed: 4/4 changed files
- Comments generated: 3
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
| Limit on concurrent pull requests | ||
| +++++++++++++++++++++++++++++++++ | ||
|
|
||
| To keep the review queue manageable, contributors without write access to |
There was a problem hiding this comment.
I'd spell out the reason more clearly. Something in the lines:
Due to the increase of opened Pull Requests by AI bots and in order to keep the review queue manageable, ...
There was a problem hiding this comment.
🟢 Approval recommended
The workflow design and enforcement logic look sound, with only minor wording/link consistency tweaks suggested in review comments.
Review details
Suppressed comments (2)
Previously missed (1) — in code that hasn't changed since the last review.
.github/workflows/pr_limit/comment.md:24
- The explanatory comment says Arrow “limits contributors … to ${PR_LIMIT} concurrently open pull requests”, which reads like an exact number rather than a maximum. Using “to at most ${PR_LIMIT}” makes the message clearer and matches the documented behavior (a maximum open-PR cap).
This issue also appears on line 30 of the same file.
.github/workflows/pr_limit/comment.md:31
- The “See also” links mix the dev docs base URL (
/docs/dev/...) with the non-dev base (/docs/...). Using a single base avoids sending users to a different doc version (and reduces the chance the new#pr-limitanchor only exists on one of them).
* [Contribution Guidelines - Limit on concurrent pull requests](https://arrow.apache.org/docs/dev/developers/bug_reports.html#pr-limit)
* [Contribution Guidelines - Contributing Overview](https://arrow.apache.org/docs/developers/overview.html)
- Files reviewed: 4/4 changed files
- Comments generated: 0 new
- Review effort level: Lite
| async function countOpenPullRequests(github, context, username) { | ||
| const {data} = await github.rest.search.issuesAndPullRequests({ | ||
| q: `repo:${context.repo.owner}/${context.repo.repo} is:pr is:open author:${username}`, | ||
| per_page: 1 |
There was a problem hiding this comment.
Ah, perhaps it's because we are only interested in the total_count.
There was a problem hiding this comment.
🟡 Changes recommended
The user-facing reopen guidance in the docs/comment template is currently misleading for contributors who are more than one PR over the limit.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 4/4 changed files
- Comments generated: 2
- Review effort level: Lite
|
GitHub provides the official feature for this: https://github.blog/changelog/2026-06-17-limit-open-pull-requests-for-users-without-write-access/ How about adding support for this in https://github.com/apache/infrastructure-asfyaml and using |
|
apache/infrastructure-asfyaml#111 is implementing the feature. |
|
@kou They are, but it's taking time to get merged and in the meantime we're still getting all these PRs. How about we use this for now and once the official one is available, we switch to that? |
|
Ah, sorry. I missed that you already know it. I found an INFRA issue: https://issues.apache.org/jira/browse/INFRA-28033 I've added a comment on the issue. Could you wait for a few days before we proceed this? |
Sure. |
Rationale for this change
Too many low-quality or drive-by AI-generated PRs from non-committers blocking up review capacity
What changes are included in this PR?
Prevent non-committers opening more than 3 concurrent PRs. This may be a little annoying for those who are engaging with effort, but PRs can be reopened later and so is an overall net positive.
Committers can reopen closed PRs on behalf of non-committers without this triggering.
Are these changes tested?
I'll test on my fork
Are there any user-facing changes?
No
AI Usage
Generated this, but asked questions about security etc