--why's closing line can say "would merge" while the published check refuses nf-5t9 ← Beads

open priority 2 task unassigned

Twinned from https://github.com/cfsh/ninefold/issues/839 by tools/beads/import_github.py's reconcile pass.

Waived twice during #829's review as sub-floor, filed here so it is not lost. Unclaimed.

merge_pr.explain() prints the published merge-authority check run and, when it disagrees with the local recompute, says so loudly — but the final line is computed only from the authority and the presubmit ledger. So a PR whose required check is red or absent still ends with:

-> would merge on HUMAN APPROVAL (perimeter not consulted).

The ⚠ lines above it are correct and carry the remedy, so nothing is hidden. But the last line is the one a session acts on — explain()'s own comment says exactly that — and "would merge" over a head GitHub will refuse is the same overstatement #825 existed to remove, one layer up.

Observed live on #829's own merge: --why ended would merge, and gh pr merge was then refused with *"the base branch policy prohibits the merge"*.

Shape of the fix: carry the published-check state into the closing branch the way the presubmit verdict already is — e.g. -> would merge on <authority>, but GitHub's required check is <state> (see above). Care needed on the absent case, which merge_pr.py heals by republishing immediately before merging, so it should read as a caveat rather than a refusal.

Not a refusal. --why returning non-zero here would be wrong: merge() republishes the check itself, so on a box with the reviewer PEM the merge really does proceed.

Refs #825, #763.

Dependencies

None.

Comments

No comments.

Add a comment