Skip to content

feat(pull_requests): add get_ci_summary method to pull_request_read tool#2261

Open
mikelane wants to merge 1 commit into
github:mainfrom
mikelane:upstream/get-ci-summary
Open

feat(pull_requests): add get_ci_summary method to pull_request_read tool#2261
mikelane wants to merge 1 commit into
github:mainfrom
mikelane:upstream/get-ci-summary

Conversation

@mikelane

Copy link
Copy Markdown

Summary

Adds a get_ci_summary method to the existing pull_request_read tool that aggregates combined commit status and check runs into a single result with an overall verdict.

Problem: Determining if a PR's CI is passing currently requires two separate calls (get_status for combined commit status + get_check_runs for individual runs), plus client-side aggregation logic. This is the most common multi-step query in MCP-based workflows.

Solution: A new method that returns one structured response with:

  • An overall verdict: passing, failing, pending, or no_checks
  • Counts: totalCheckRuns, passing, failing, pending
  • Per-check details with name, status, and conclusion
  • A failingChecks array for quick triage

Example output

{
  "verdict": "failing",
  "combinedStatus": "failure",
  "totalCheckRuns": 3,
  "passing": 2,
  "failing": 1,
  "pending": 0,
  "checks": [
    {"name": "CI / test", "status": "completed", "conclusion": "success"},
    {"name": "CI / lint", "status": "completed", "conclusion": "success"},
    {"name": "CI / build", "status": "completed", "conclusion": "failure"}
  ],
  "failingChecks": ["CI / build"]
}

Changes

  • pkg/github/pullrequests.go — Added get_ci_summary to the method enum and switch, implemented GetPullRequestCISummary and computeCIVerdict helper
  • pkg/github/pullrequests_test.go — 7 test cases covering: all passing, combined failure, check run failure, in-progress, no checks, mixed, and PR fetch error
  • pkg/github/__toolsnaps__/pull_request_read.snap — Auto-updated

No new files, no new dependencies. Follows the exact patterns of adjacent methods (GetPullRequestStatus, GetPullRequestCheckRuns).

Verdict logic

Uses an allow-list approach (require known-good, not reject known-bad):

  • passing — combined status success AND all check runs completed with success/neutral/skipped
  • failing — combined status failure/error OR any check run with failure/cancelled/timed_out/action_required
  • pending — any check run not yet completed, or combined status pending with active statuses
  • no_checks — combined status pending with zero statuses and zero check runs

Test plan

  • go build ./... passes
  • go vet ./... passes
  • golangci-lint run — 0 new issues
  • go test ./pkg/github/... -count=1 — all tests pass, no regressions

🤖 Generated with Claude Code

@mikelane mikelane requested a review from a team as a code owner March 25, 2026 02:59
@mikelane mikelane force-pushed the upstream/get-ci-summary branch from 7e8d487 to 1a62381 Compare March 25, 2026 03:19

@nova001ops nova001ops left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

# > `~~~~`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants