Block stale and unstable merge states#24
Conversation
mberman84
left a comment
There was a problem hiding this comment.
Requesting changes because the blanket UNSTABLE classification regresses the exact-main integration path. Merging this head onto current main fails test_integration_snapshot_uses_exact_commit_check_fallback (blocked instead of ready). Preserve the useful BEHIND handling, but derive failed vs waiting from configured required-check states and do not override successful exact-commit evidence. GitHub CI is still action_required; re-request review after updating the head.
| blocked.append( | ||
| f"GitHub reports the pull request merge state as {self.merge_state}" | ||
| ) | ||
| elif self.merge_state == "UNSTABLE": |
There was a problem hiding this comment.
UNSTABLE means a non-passing commit status, which can be pending or an optional failure. Treating it unconditionally as blocked turns ordinary CI into a repair escalation and also blocks current main's integration fallback after exact required CI has passed. Use the reduced required-check states to distinguish failed from waiting, and allow exact successful evidence to remain ready.
767ead0 to
375a9a2
Compare
|
Addressed the review feedback in the updated head. Verification: |
Treat GitHub BEHIND and UNSTABLE merge states as non-ready so the queue reports the real blocker instead of ready-to-merge status. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
375a9a2 to
bb50ac3
Compare
mberman84
left a comment
There was a problem hiding this comment.
Re-reviewed on the latest main. BEHIND fails closed; UNSTABLE waits only without exact required-check proof and preserves exact-success integration behavior. Full suite: 227 passed, 3 skipped, 202 subtests; Ruff and structured autoreview clean.
Summary
Closes #18
Validation