Repository navigation
ci: a no-verdict compile is never a base red; shas are masked in compared error lines - #26816
Conversation
…r lines base_red_excuse compared error lines with digits masked, so the fleet Release compile's "cmux-next/compile is not a pass for <sha> (no result)" never matched between a PR and the base. Masking the sha alone would have excused it, letting a Swift PR land with nothing having compiled it. Now a compile check with no verdict (no result / unavailable / mismatch / unreadable, or the app compile's "No build-fleet verdict") is refused, whatever the base shows. It is set aside only when the same head has a real compile pass: a green "cmux-next Release compile (Xcode 26)" check run or a cmux-next/compile success status. next-batch keys such a job by its own job id so the base never excuses it. Commit shas (7-40 hex with a digit and a letter) are masked in compared error lines, so a real red that names each run's own commit still matches. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-85ca59f74f02d81734c3
|
Owned by an agent session · session |
|
cmux status (one comment, edited in place; each line is updated by the job that owns it) Review App of this head (app.zip, kept 1 day)
red: cmux-next checks (god files, concurrency, crash safety, l10n); NEW: |
…echoed script Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-85ca59f74f02d81734c3
This comment has been minimized.
This comment has been minimized.
|
Bead |
…shas only Review findings on #26816: - compile_pass_at took any green "cmux-next Release compile (Xcode 26)" check run, a name release-compile-fast-admission shares, an older pass over a newer failed attempt, and a null head_sha. It now reads the job of each check run at the exact sha, newest first, counts only jobs with the Mac compile's own steps (Release compile / Reuse that pass), and the newest of those decides. - SHA masked any mixed-hex id. It now masks a full 40-hex sha, or 7-39 hex right after a word that names a commit (commit, sha, tree, head, base, revision, ref, at, for); other hex ids are compared as they are. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-85ca59f74f02d81734c3
Bugbot needs on-demand usage enabledBugbot uses usage-based billing for this team and requires on-demand usage to be enabled. A team admin can enable on-demand usage in the Cursor dashboard. |
Review findings on #26816 (second round): - Of compile-status's own error lines, only "(fail)" is a real compile red; every other state (pending, pass it could not post, last: ...), "could not post the pending status" and "bad head sha" are no verdict. - next-batch keys an unreadable log of a no-verdict-capable compile job by its own job id. - Commit sha masking: a full 40-hex sha, or 7-39 hex after commit, sha, tree or revision (any hex, so "commit 1234567" too); generic words like "for" or "at" no longer mask. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-85ca59f74f02d81734c3
A check run id is not guaranteed to be its Actions job id. compile_pass_at now takes the job from details_url (as main_fix_evidence.job_for does) and checks its run, sha and name; the tests give check runs and jobs different ids. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-85ca59f74f02d81734c3
|
Found 11 test failures on Blacksmith runners: Failures
...and 1 more test failures. View all on Blacksmith
|
judge() set aside any failed job printing a no-verdict line once a compile pass existed; a non-compile job's real red could ride on it. Only jobs in NO_VERDICT_JOBS take that branch now. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-85ca59f74f02d81734c3
|
The feat-cmux-next push run https://github.com/manaflow-ai/cmux/actions/runs/40693729434 at 3df9106 failed: cmux-next checks (god files, concurrency, crash safety, l10n). |
|
Shipped in:
|
![Fix with [code]smith](https://pr-comments-assets.blacksmith.sh/codesmith/fix-with-codesmith-light-3x.png)
Follow-up to #26798.
scripts/ci/base_red_excuse.py(used bygh-merge-green) and next-batch decide whether a red on a PR is "the same red as the base". The fleet Release compile's red while the controller was wedged iscmux-next/compile is not a pass for <sha> (no result). Error lines were compared with only digits masked, so the PR's line and the base's line never matched because each names its own sha. Masking shas alone would have been wrong, though: it would excuse a compile that compiled nothing, and a Swift PR could land unbuilt.The rule this PR enforces: a fleet compile "no result" is an infra non-verdict, not a test failure. It is never excused as a base red, even when the PR and base show the identical normalised error. It may be set aside only when another job at that same head gave a real compile pass: the Mac Release compile fallback green, or
cmux-next/compilesuccess.Change
base_red_excuse.judge: a failed job whose log says it gave no compile verdict is refused, whatever the base shows. It fails closed: of compile-status's own error lines, onlycmux-next/compile is not a pass for <sha> (fail)is a real compile red. Every other state (no result, unavailable, mismatch, unreadable, pending,last: ...),could not post the pending statusandbad head shacount as no verdict, as does the app compile'sNo build-fleet verdict for ...from ci(cmux-next): a build-fleet app compile with no verdict fails, never green #26798. Only the job's own##[error]lines count, never the script text the log echoes. It is set aside, with an audit lineignored '<job>': ... compiled <sha> and passed, only when one of these holds at the same head:cmux-next Release compile (Xcode 26)) at that exact sha concludedsuccess, with itsRelease compileorReuse that passstep green. The newest attempt decides, so an older pass doesn't count over a newer failure.release-compile-fast-admission, a Linux wrapper with the same check name, has neither step and never counts. A check run whose sha is null or different doesn't count either;cmux-next/compilecommit status issuccess.next_batch.expand_job: such a job, or an unreadable log of a compile job that can end without a verdict, is keyed by its own job id (no compile verdict (job N, never a base red)), the same way crashes already are, so a base probe never excuses it.commit,sha,tree,revision), any hex digits at all there. Any other hex id, such as an artifact hash, is compared as is. A real red that differs only by the commit it names is still excused. Nothing else gets looser: steps, test names, crash and truncation rules are unchanged.Tests
tests/test_base_red_excuse.pyNoVerdictCompileIsNeverABaseRed:cmux-next/compilesucceeded, but not when the newest status is failure;artifact deadbeef1vsartifact abcdef12,for deadbeef1vsfor abcdef12) are not equated;(fail)is no verdict, and a real(fail)is compared with the base;tests/test_next_batch.py: a no-verdict compile is keyed by its own job.test_base_red_excuse,test_next_batch,test_next_batch_groupsandtest_test_redsall pass (244 tests). Checked against the real logs too: both "no result" fleet Release compile jobs and the "No build-fleet verdict" app compile job are recognised, and the [launch-polish] Add native human setup guide #26741 green log is not.Risk: low. Every change except the sha mask makes the excuse stricter. The sha mask only ever applies after a no-verdict compile has already been handled.
Agent session: agent session
🤖 Generated with Claude Code