Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

pull_request_read: support response field filtering

Offen
  • Stimmt etwas nicht?
#3,286 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
github, go
Bereich
api, backend

Rechercherichtung

Beginne am Einstiegspunkt pull_request_read und vergleiche, wie die Filterung von Feldern in list_pull_requests und search_pull_requests funktioniert. Verfolge jede aufgeführte Methode, insbesondere get_reviews und get_check_runs, um zu ermitteln, wie Antwortfelder dargestellt und validiert werden. Fertig ist die Arbeit, wenn Aufrufer ausgewählte Felder anfordern können, ohne unnötige Payload-Daten zu erhalten, und bestehende Aufrufe weiterhin kompatibel sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

enhancement request ai review
Describe the feature or problem you’d like to solve

list_pull_requests and search_pull_requests both support a fields parameter to trim response size to only what the caller needs. pull_request_read has no equivalent for any of its methods (get, get_diff, get_status, get_files, get_commits, get_review_comments, get_reviews, get_comments, get_check_runs) — every call always returns the full, maximally verbose payload.

This is a significant problem for get_reviews and get_check_runs specifically:

  • get_reviews returns the full review body for every review, even when the caller only needs state and user.login to compute a review decision. Bot-generated reviews (e.g. Copilot code review) can each be several KB of markdown.
  • get_check_runs returns a fully itemized list of every check run (name, URL, timestamps, etc.) even when the caller only needs an overall pass/fail signal — get_status already provides that more cheaply, but doesn't help when a specific failing check's name is needed.

In practice, this forces callers who just want a compact per-PR summary (review decision + CI status) into fetching and carrying far more data than necessary.

Proposed solution

Add a fields (or select) parameter to pull_request_read, consistent with the existing pattern on list_pull_requests/search_pull_requests:

  • For get_reviews: allow selecting a subset of {id, state, user, submitted_at, body} per review, defaulting to omit body.
  • For get_check_runs: allow a fields filter over per-check fields (name, conclusion, url, timestamps, etc.).

This lets callers request only the compact signals they need, keeping response size proportional to what's actually useful — the same benefit fields already provides on list_pull_requests and search_pull_requests.

Example prompts or workflows (for tools/toolsets only)
  • "Summarize the review and CI status of every open PR across these 7 repositories" — an agent lists PRs per repo, then for each PR calls pull_request_read with method: get_reviews, fields: [state, user] and method: get_check_runs, fields: [name, conclusion] to build a compact status table, instead of ingesting full review bodies and full check-run details it never uses.
  • Any dashboard/digest/reporting tool that needs "is this PR approved and green?" for many PRs at once, without paying the cost of full review text and full check-run metadata per PR.
  • Bulk PR triage workflows that classify PRs into buckets (needs review / blocked / ready to merge / stale) based only on review state and CI pass/fail, run across many repositories in a single pass.
Additional context

We hit this concretely in an automation agent that summarizes open PRs across several repositories into a digest: listing PRs, then calling get_reviews + get_check_runs per PR to classify each one, accumulated roughly 660KB of conversation context across ~110 tool calls (full unfiltered payloads for each call). The agent's next step then timed out entirely before producing any output. A single compact call per repository via GitHub CLI's gh pr list --json reviewDecision,statusCheckRollup,... returns equivalent information in a fraction of the size, precisely because it lets the caller select only the fields it needs — the same capability pull_request_read is missing.

Vorherrschende Sprache
Go
Sterne
33.1k
Forks
5k
Ø Merge
2 T. 3 Std.
Gemergte PRs (30 T.)
18

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus github/github-mcp-server

Alle Issues in github/github-mcp-server

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.