nightly-next: the 30-minute tick is the only automatic promotion

TE
9d ago
+240-65

Every landing on feat-cmux-next dispatches its own nightly-next promotion today, so a burst of landings starts a build per landing, and a landing request can evict the tick's request in the nightly-next-promote concurrency group. With this change, the 30-minute tick (nightly-next-tick.yml, cron 7,37) is the only automatic promotion. Each tick starts at most one build, of the newest tip.

  • nightly-next-tick.yml: the tick's gh shim marks every promote_nightly_next_sha= argument as tick:<sha>. That covers -f, -fk=v, --field=, -F and --raw-field.
  • nightly.yml: the promote job runs only for a tick: request or a dispatch by someone other than github-actions[bot]. A per-landing request is skipped before it can enter the concurrency group, so it can neither evict nor delay a tick.
  • promote-nightly-next.mjs: decideRequest applies the same rule again, then calls decideNewest. The evicted-request recovery ignores landing requests. A tick with nothing newer than the feed does nothing.
  • A person's workflow_dispatch still promotes as before. Started builds are never cancelled, and publishing stays latest-wins.

The companion feat-cmux-next PR stops request-nightly-next.sh from dispatching per landing, and its train drive marks its request with tick:.

Changelog

none

Tests

tests/test_nightly_promotion_admission.py and tests/test_nightly_delivery_concurrency.py add these cases:

  • a burst of landings promotes nothing;
  • the tick promotes through the newest-request guard;
  • a tick with nothing new does nothing;
  • a person's dispatch still promotes;
  • dry-run and tick prefixes parse in either order;
  • an evicted landing request is not decided, and an evicted tick request is;
  • the tick shim marks all six argument forms and passes other commands through;
  • a landing request never enters the promote queue.

Observed / Not run

  • Observed: on Linux through cmux-ci test, the promotion_admission, delivery_concurrency, promotion_queue, ci_nightly_off_blacksmith and nightly_next_cancelled_tip suites gave 132 passed and 1 skipped at this head.
  • Observed: a Codex gpt-6-astra xhigh review of 377348940943..0da65247 together with the feat companion returned SHIP. It found that a landing request can no longer evict or delay a tick, that the retired ack jobs are statically disabled, and that feed-watch only counts queued or in-progress delivery runs. An earlier round's P1 (landing requests evicting the tick) is fixed in 0da65247.
  • Not run: a live tick on main. The first tick after merge is the live check.

Agent session: agent session

🤖 Generated with Claude Code

View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need.

Summary by cubic

Makes the 30-minute tick the only automatic promotion path for nightly-next. Previously, every landing on feat-cmux-next dispatched its own promotion, so a burst of landings started one build per landing; now each tick (nightly-next-tick.yml, cron 7,37) starts at most one build, of the newest tip.

  • The tick's gh shim marks every promote_nightly_next_sha= argument with the tick: prefix, for all argument forms (-f, -fk=v, --field=, -F, --raw-field).
  • Main's promote job and decideRequest skip per-landing requests from github-actions[bot] before they enter the nightly-next-promote concurrency group, so they can neither evict nor delay the tick's request; evicted-request recovery applies the same rule.
  • A person's workflow_dispatch still promotes as before; started builds are never cancelled and publishing stays latest-wins.
  • Tests cover the tick-only cadence, request prefix parsing, and evicted-request recovery.

Summary by CodeRabbit

  • Chores
    • Nightly build checks now run on a scheduled cadence, with manual runs still available.
    • Nightly promotion requests are handled according to their request type and source, helping keep unrelated requests separate.