All supported GHES versions (3.16 through 3.20) support the
checkRunCountsByState and statusContextCountsByState fields on
StatusCheckRollupContextConnection. The slow path that iterated
individual CheckContext nodes in ChecksStatus() is dead code.
This commit:
- Removes the slow path from ChecksStatus(), keeping only the
aggregated counts-by-state path
- Removes parseCheckStatusFromCheckConclusionState (no callers remain)
- Removes CheckRunAndStatusContextCounts from PullRequestFeatures
and its introspection detection
- Consolidates the two feature detection introspection queries into
one (PullRequest + WorkflowRun fits within the platform limit of
two __type expressions)
- Removes the errgroup dependency from feature detection
- Always uses statusCheckRollupWithCountByState in pr status queries
- Updates pr view fixtures to include counts-by-state fields
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
When a GitHub Actions workflow uses concurrency with cancel-in-progress,
cancelled runs were counted as failures in `gh pr status` and
`gh pr view`, even when a newer run for the same check name succeeded.
The GitHub web UI and `gh pr checks` both handle this correctly.
Three changes fix this:
1. Add a `cancelled` check status category. Cancelled runs are now
excluded from all summary counts (passing/failing/pending) and
subtracted from the total, matching the web UI behavior.
2. Move `eliminateDuplicates` from pkg/cmd/pr/checks to
`api.EliminateDuplicateChecks` (exported). The function operates
entirely on `api.CheckContext` and is now shared by both `pr checks`
and `ChecksStatus()` (used by `pr status` and `pr view`).
3. Apply deduplication in the `ChecksStatus()` slow path, keeping only
the most recent run per check name — consistent with `pr checks`.
Fixes#12895
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The "STALE" conclusion has shipped this January and is basically a
conclusion that can only be reported by GitHub and not explicitly set by
any integrations.
Fixes `panic: unsupported status: ""`
This occurs when a CheckRun has status "IN_PROGRESS" (or any other than
"COMPLETED") and when its `conclusion` would be null. I previously
didn't account for this.
This adds support for parsing state of an in-progress CheckRun.
