#32689 ci(nightly-next): the tick does not promote a commit whose app is already published

Leo: "and why are there so many nightlies? are these true updates?" and then "don't slow down nightlies btw".

Answer from the last 24 h (to 23:30Z on 2026-11-02): 93 NEXT nightlies published. Running scripts/ci/nightly_build_inputs.py (the classifier main's nightly already skips with) over each published build and the one before it, only 3 of 92 were app-identical: 1 was the same commit published twice, and 2 changed only CI and test paths. Each published build carried a median of 28 changed files. So they are true updates: the volume comes from about 1,100 landings a day.

This PR drops those few app-identical builds without slowing any real one:

• request-nightly-next.sh reads the nightly-next tag (the commit the feed last published; the publish moves the tag there) in the same git ls-remote that already reads the nightly-next branch. That is one round trip, as before, and it still reads no API.
• request() passes over a commit when the classifier finds nothing that reaches the app between the published commit and it. The tick's walk stops on that commit ("already on nightly-next"): an older commit changes even less.
• No delay to a real update. An app-changing landing is always in the diff from the published commit, so the next tick promotes it exactly as today. Any doubt also promotes: no published commit, history too shallow, a commit that doesn't descend from the published one, or a classifier that fails.
• Cost. The classifier stops at the first app-changing path: 0.04 s on a real tip. It only runs a full pass when nothing changed, and then nothing is promoted anyway. No step is added to nightly.yml or to the build.

Tests: scripts/cmux-next/tests/request-nightly-next.test.sh gains cases for these behaviours:

• an app-identical commit is not promoted, and the message stops the tick's walk;
• the next app change is promoted;
• a failing classifier still promotes;
• with no published tag, the commit is promoted.

The test fails without the change and passes with it. Also run and passing: test_tui_publish_workflow_security.py, test_cmux_tui_artifacts_linux_runner_set.py, test_cmux_next_checks_workflow.py, test_ci_nightly_off_blacksmith.py, test_cmux_next_route.py, test_cmux_tui_publish_retries.py, test_cmux_tui_feat_publish_order.py, test_cmux_tui_owner_wait_defers.py. Shellcheck shows only the one warning already on base.

A follow-up teaches the freshness check to measure lag against app-changing landings only, so a stretch of CI-only landings doesn't read as a stale feed.

Agent session: agent session

🤖 Generated with Claude Code

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Stops the nightly-next tick from building and publishing a commit whose app is already on the feed. Of 92 NEXT nightlies published on 2026-11-01/02 only 3 were app-identical, but each costs a full build, signing, and two notarizations.

The tick now reads the nightly-next tag — the commit the feed last published — in the same git ls-remote call that already reads the branch, so there is still one round trip. When scripts/ci/nightly_build_inputs.py finds nothing app-changing between the published commit and a candidate, the candidate is skipped and the tick's walk stops there.

Behavior changes

• An app-identical commit is skipped with a message that stops the walk; an app-changing commit is promoted exactly as before.
• Any doubt still promotes: no published tag, shallow history, a non-descendant, an unreadable classifier, or a bundled cmux-tui tree key that differs from the published commit's.
• With a promotion still building, the candidate must match the app nightly-next is about to publish, so a revert of an outstanding promotion is promoted at once instead of waiting for the build to finish.
• git diff --no-renames keeps the old path of a file moved out of the app, so a move is promoted and never read as docs-only.
• New tests in request-nightly-next.test.sh cover the skip, the next app change, a classifier-missed cmux-tui change, a move out of the app, a failing classifier, the outstanding-promotion revert, and a missing published tag.