Skip to content

emrg: probe - measure mergeStateStatus under a red check - #1171

Closed
argszero wants to merge 1 commit into
masterfrom
probe-merge-state-red-ci
Closed

argszero wants to merge 1 commit into
masterfrom
probe-merge-state-red-ci

Conversation

@argszero

Copy link
Copy Markdown
Owner

Throwaway measurement probe (no code change intended to land). A deliberately failing test, to answer: with no branch protection and no rulesets, does GitHub report UNSTABLE for a PR whose check has failed - or can a red-check PR still read CLEAN? The tool in #1170 treats UNSTABLE as the CI conjunct; this measures whether that state is reachable at all here. Will be closed without merging.

@argszero

Copy link
Copy Markdown
Owner Author

Closing — measurement complete, no merge intended. Result: a failed check yields MERGEABLE/UNSTABLE even with no branch protection and no rulesets, so reading UNSTABLE does catch failing CI. Separate finding: CLEAN does not imply checks ran (3 historical heads with zero check runs reported CLEAN), which the vote-count tool's own docstring assumes it does.

@argszero argszero closed this Sep 12, 2026
@argszero
argszero deleted the probe-merge-state-red-ci branch September 12, 2026 11:51
argszero pushed a commit that referenced this pull request Sep 12, 2026
…ified

MergeStateStatus counts *required* checks, and this repo has no branch protection
and no rulesets, so a head with zero check runs reports MERGEABLE/CLEAN - the same
value a double-green head reports. The docstring claimed such a PR 'is not
mergeable anyway' and used the missing run only to approximate the push time.

Measured 2026-09-12: three historical heads (c0860a3 / af2e0ef / 5358d29) have
zero workflow runs each and all three report MERGEABLE/CLEAN; a probe with that
payload reaches READY and exit 0 on three valid votes - a PR no CI has ever
judged, reported mergeable. A probe PR (#1171) also confirms the other direction:
a *failed* check does yield UNSTABLE here, so the state is trustworthy when there
is a run and silent when there is none.

So the missing run is treated as blocking, with a reason that names it (both merge
fields are clean, so 'blocked' alone gives a reader nothing to act on). Two
mutants killed: removing the clause -> 4 red; making it unconditional -> 15 red.
argszero added a commit that referenced this pull request Sep 13, 2026
… merge (#1170)

* emrg: report mergeability, so enough votes is not printed as ready to merge

* emrg: read the whole merge gate, so a draft PR is not reported ready

check-vote-count.py branched only on `mergeable` and ignored
`mergeStateStatus`, so with three valid votes it printed `READY` and exited 0 for
MERGEABLE/UNSTABLE (CI not green), /BEHIND, /BLOCKED and /DRAFT - and a draft pull
request cannot be merged by anyone. Its own docstring spelled the gate as the pair
MERGEABLE/CLEAN, and its own tests could not catch the gap: every one of them used
CLEAN or DIRTY, i.e. only the two states the code happened to branch on.

The known states are now enumerated (each with the reader's reason) and an
unrecognised one fails loud, which buys the rot-resistance the old "never branch on
the field" comment was reaching for without also passing every state it covered.

Both mutants die: disabling the unknown-state refusal and restoring the pre-fix
predicate each leave the new tests red.

* emrg: a head with no CI run is not CLEAN, it is the CI conjunct unverified

MergeStateStatus counts *required* checks, and this repo has no branch protection
and no rulesets, so a head with zero check runs reports MERGEABLE/CLEAN - the same
value a double-green head reports. The docstring claimed such a PR 'is not
mergeable anyway' and used the missing run only to approximate the push time.

Measured 2026-09-12: three historical heads (c0860a3 / af2e0ef / 5358d29) have
zero workflow runs each and all three report MERGEABLE/CLEAN; a probe with that
payload reaches READY and exit 0 on three valid votes - a PR no CI has ever
judged, reported mergeable. A probe PR (#1171) also confirms the other direction:
a *failed* check does yield UNSTABLE here, so the state is trustworthy when there
is a run and silent when there is none.

So the missing run is treated as blocking, with a reason that names it (both merge
fields are clean, so 'blocked' alone gives a reader nothing to act on). Two
mutants killed: removing the clause -> 4 red; making it unconditional -> 15 red.

* emrg: a vote that does not count must not be labelled counts

---------

Co-authored-by: EMRG Evolution <emrg@argszero.dev>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant