fix(github): block applies when a required check has not reported

[morgo]

When required_checks is configured, the passing-checks apply gate only evaluated the required checks GitHub had already reported on the PR commit. A configured required check that had not reported yet neither failed nor counted as in-progress, so the apply could proceed before that check ever ran — a fail-open gap in a tier-0 safety gate.

This treats every configured required check that is absent from the fetched statuses as a not-yet-reported in-progress blocker, mirroring how a legacy commit status in the EXPECTED state maps to in_progress. The gate now fails closed and the apply-blocked comment names the missing required check(s) so the operator knows what still has to report.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR closes a fail-open gap in the GitHub “passing checks” apply gate when required_checks is configured: required checks that have not yet reported on the commit are now treated as blocking (in-progress) so apply cannot proceed until they appear.

Changes:

• Treat configured required checks absent from fetched PR statuses as in-progress blockers and include them in the apply-blocked comment.
• Add logging to distinguish total in-progress blockers vs. missing-required blockers.
• Add unit/integration-style tests covering missing required checks behavior and enforcePassingChecks end-to-end comment output.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
pkg/webhook/apply_gating.go	Adds missing-required detection and folds missing required checks into the in-progress apply gate path.
pkg/webhook/apply_gating_test.go	Adds coverage for missingRequiredChecks and new enforcePassingChecks scenarios where required checks haven’t reported yet.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[aparajon]

The fail-closed mechanics are right: missingRequiredChecks only runs after a successful status fetch, the three causes (API/permission failure, failing checks, never-reported checks) keep separate branches with distinct handling, no path converts an API error into a pass, and the REST fetch paginates fully. Name matching is consistent with IsCheckRequired. The safety direction is correct — but the operator-facing message needs a change before merge:

1. A never-reported check renders as "still running… wait and retry" — for the realistic causes (typo in required_checks, check not configured on the repo, path-filtered workflow), the check will never report, and this advice sends an operator into an indefinite wait. The table's "not reported" row helps, but the remediation text is wrong for those rows. Suggest a conditional paragraph when missing checks exist: "<name> has not reported on this commit. If it never reports, verify the name in required_checks matches the check exactly and that it runs on this PR."

2. Log the missing names — "apply blocked by in-progress PR checks" with a missing_required_count conflates two causes in one message. When missing checks are the blocker, log them by name so triage doesn't require reproducing the gate.

3. Nit: a SchemaBot-owned check counts as "reported" here (correct — avoids self-deadlock), but an aggregate-check entry in required_checks is then silently unenforced by this gate. Consider config validation rejecting it explicitly.

Verdict: needs changes for the message; mechanics are sound.

---

🤖 This review was generated by Claude Code (claude-fable-5) with maintainer approval.