Add GitHub pull request creation cap support - #111
Conversation
Implements the pull request creation cap interaction limit (community/maintainers#840), which limits the number of open pull requests a user without write access may have open at one time via the PATCH /repos/{owner}/{repo}/interaction-limits/pulls/ creation-cap endpoint. Configured under github.pull_requests.creation_cap with `enabled` and an optional `max_open_pull_requests` (1-1000). Removing the section disables a cap previously managed by .asf.yaml. Includes tests and README docs. Generated-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
939fcb8 to
7286ea7
Compare
o-nikolas
left a comment
o-nikolas
left a comment
There was a problem hiding this comment.
Would love to see this supported by asf.yaml
|
Hello dear infra - could we get it reviewed and merged? We need to have some tools to at least attempt to fight with the AI slop. |
|
We would certainly use this in apache/arrow. Thanks @potiuk for pushing this. |
| print("Disabling pull request creation cap") | ||
|
|
||
| if not self.noop("pr_creation_cap"): | ||
| self.ghrepo._requester.requestJson("PATCH", _creation_cap_url(self), input=payload) |
There was a problem hiding this comment.
You should check the return value of the call.
There was a problem hiding this comment.
Good catch — fixed in 6f5addf. The PATCH result is now checked with the same pattern rulesets.py uses: non-2xx raises with the detail extracted from the response body (errors → message → raw body), with specific messages for 403/404/422/500 and a generic one otherwise.
I accept any 2xx rather than one exact code, because GitHub hasn't published REST docs for this endpoint yet (the schema came from the OpenAPI description), so I'd rather not hard-code a status that might turn out to be 204. Added tests for the error paths and for a 204 body.
Addresses review feedback: the PATCH to the interaction-limits endpoint silently ignored failures. Follow the pattern used by the rulesets directive and raise a descriptive exception for non-2xx responses (403/404/422/500 get specific messages, anything else a generic one). Also add a note that an omitted max_open_pull_requests is intentional: the key is left out of the payload so GitHub applies its own default.
4 participants
What
Implements support for GitHub's pull request creation cap
— an interaction limit that caps how many open pull requests a user without write access may have
open at one time. Users with write access are unaffected.
It uses the
PATCH /repos/{owner}/{repo}/interaction-limits/pulls/creation-capendpoint (schema takenfrom GitHub's OpenAPI description, since the REST docs were not yet published when the changelog went out).
Configuration
Nested under the existing
github.pull_requestsblock:enabled: falseturns the cap off.creation_capsection disables a cap that was previously managed by.asf.yaml.Changes
asfyaml/feature/github/__init__.py—creation_capstrictyaml schema + directive registrationasfyaml/feature/github/pr_creation_cap.py— new directive (payload build, 1–1000 range validation,disable-on-removal, noop-aware, idempotent PATCH)
tests/github_pr_creation_cap.py— 9 tests (schema validation + enable/disable/removal/out-of-range/noop)README.md— new "Pull request creation cap" subsection + ToC entryTesting
Full suite passes (105 tests),
ruffandmypyclean on the new code.