feat: PR-checks verdict (skipped != failed) + create_issue & CI rerun tools#1
Conversation
Improve get_pull_request_checks to return a verdict that distinguishes skipped from failed checks. Classify every check-run and commit-status context into passed/failing/pending/skipped buckets and expose a ready_to_merge signal (no failing/pending and not known-unmergeable). Skipped (skipped/neutral) checks are no longer misread as failures. Add write tools for the foreman loop: - create_issue (issues.py) - list_workflow_runs, rerun_workflow_run, rerun_failed_jobs (actions.py) rerun POSTs tolerate GitHub's empty 201 body and synthesize a success dict. Register all new tools (create_issue_tool, list_workflow_runs_tool, rerun_workflow_run_tool, rerun_failed_jobs_tool). Bump version 0.1.0 -> 0.2.0 in pyproject.toml and Containerfile. Add tests covering the verdict classification, create_issue, workflow-run unwrapping, and empty-body reruns. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces several new GitHub MCP tools, including capabilities to create issues, list workflow runs, and re-run workflow runs or failed jobs. It also refactors the pull request check-run and commit-status classification to explicitly bucket checks into passed, failing, pending, or skipped, and computes a ready_to_merge flag. Feedback on these changes suggests classifying startup_failure and stale check-run conclusions as failing rather than pending, and ensuring ready_to_merge is only set to true when mergeability is explicitly confirmed as True (rather than just not False) to avoid race conditions while GitHub is still calculating mergeability.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| case ( | ||
| "failure" | "cancelled" | "timed_out" | "action_required" | ||
| ) as conclusion: |
There was a problem hiding this comment.
The check-run conclusions "startup_failure" and "stale" are currently not matched, which means they will fall through to the case _: block and be classified as "pending". However, both of these represent completed runs that did not succeed (a startup failure is a critical configuration/execution failure, and a stale run is one that was superseded or timed out). They should be classified under the "failing" bucket instead of "pending" to accurately reflect their completed and non-successful status.
| case ( | |
| "failure" | "cancelled" | "timed_out" | "action_required" | |
| ) as conclusion: | |
| case ( | |
| "failure" | "cancelled" | "timed_out" | "action_required" | "startup_failure" | "stale" | |
| ) as conclusion: |
| ready_to_merge = ( | ||
| not failing and not pending and mergeable is not False | ||
| ) |
There was a problem hiding this comment.
When mergeable is None, it indicates that GitHub is still calculating the mergeability of the pull request (which often happens immediately after a PR is created or updated). Treating ready_to_merge as True in this state can lead to race conditions where automated tools attempt to merge the PR before GitHub has verified there are no conflicts, resulting in failed merge attempts. Changing this to mergeable is True ensures we only signal readiness when mergeability is explicitly confirmed.
| ready_to_merge = ( | |
| not failing and not pending and mergeable is not False | |
| ) | |
| ready_to_merge = ( | |
| not failing and not pending and mergeable is True | |
| ) |
1 participant
Summary
Closes the loop-hole where the foreman treated skipped CI checks as failures and lacked tools to file follow-ups / rerun CI.
get_pull_request_checksrewritten to return a verdict:ready_to_merge,mergeable/mergeable_state, and per-bucketpassed/failing/pending/skipped. Skipped/neutral are not failures. (Verified live on mcp-ashigaru PR#3 →ready_to_merge=True, ghcr inskipped.)create_issue— file follow-up issues.list_workflow_runs,rerun_workflow_run,rerun_failed_jobs— inspect/retrigger CI.Test plan
list_workflow_runson this repo.🤖 Generated with Claude Code