The queue of repaired commits

This page continues Walkthrough: release end-to-end after its workspace plan and before its submit step.

stado serve --release-loop-root ~/src
stado release newest --plan

Every commit that carries a repair recorded in Oko (oko defects repaired --revision) is queued for its release with its defects named. Per checkout the queue reads the workspace plan and the open defects whose recorded repair the commit contains. A commit carrying none owes nothing (nothing_carried). One carrying some is queued at the first step it needs: version when its version is taken (the least next version the versioning rule allows), release, or record when a release already carries it. The serve role queues at start and whenever a checkout's branch moves; --plan queues and prints the queue (queue in --json). Queueing builds and commits nothing, but a commit is first put through its product's format gates and the lock check over its committed tree, which compile nothing: one committed unformatted or with a lock its manifest outgrew is failed at gates, with the gate's refusal on its defects, before anyone builds on it.

The steps run only in stado release newest, the release command the build gate admits or refuses: the version is committed in the product's version_source with its Cargo.lock entry moved offline, the commit goes through the walkthrough's submit and qualification pipeline, and the release is recorded with oko defects released --product <product> --close --tasks: every defect whose repair it carries is closed, and every task whose acceptance checks are all recorded met and whose evidence commit it carries gets its done verdict by the release, without asking the judge. Each commit's outcome is kept in ~/.stado/release-loop.json: queued, running, delivered, nothing_carried, or failed at carried, gates, version, release or record with that step's exact error, recorded naming the defects and the tasks (task-…) it closed. A failure is also a note on every carried defect — stado release loop: <product> at <commit> did not reach a release; the <step> step refused: <error> — and fails the command naming the product. A commit that failed at gates, version or release is not taken again; the product's next commit is. A failed record is: the release stands published, so the next pass only records it — an Oko that predates --tasks refuses until it is delivered itself. The version step refuses by name, and commits nothing, when the version file or lock carries someone's uncommitted change or the checkout moved while it was planned.

stado release newest --plan --first stado,tama,oko,skarbiec,brama,jeden
stado release newest --first stado,tama,oko,skarbiec,brama,jeden

--first sets the delivery order: the products it names go first, in that order (repeat the flag or separate names with commas), and every other product follows in name order — the queue's commits in that order, then the other releasable products in that order. A name the plan does not hold is refused: --first <name> names no product of this plan; it holds <products>. Without it the order is the products' names.

Every push runs the repository's pre-push gate, and that gate is one of the products the queue delivers: pushing before it is delivered meets the old gate, which refuses what the new one admits. So a workspace with unpushed work starts in this order:

stado release newest --push --first tama

--push delivers the --first products (built, tested, published), installs each on this host with stado product install, and only then runs git push in every checkout of the workspace that holds commits its upstream does not — through the newly installed gate — and reads stado ci status <product> --revision <pushed commit> for each pushed product; then it delivers the rest. A --first product whose queued commit failed a step, or whose install refused, is not installed, and no checkout is pushed: each says not pushed: the products every push needs first are not installed (<product>: <why>). Without --first, --push is refused before any step runs. The unpushed commits of every checkout are counted before and after the pushes (unpushed before / unpushed after lines, push {before, installed, pushed, after} in --json); --plan prints the same count (unpushed), and a checkout with no upstream names git's refusal instead of a count. A push that did not land fails the command like a refused release. Real journey: tests/release/newest/push-order.mjs.

--plan over the whole workspace (no --product) also lists every open repair no checkout carries, under unplaced in --json and as unplaced <defect> <repository>@<commit>: <why> in text, so a repair the queue would never deliver is seen before the run, not after it. The reasons: <root> holds no checkout of <repository>; the workspace's checkout <repository> declares no product release (.wisent-release.json), so no release carries it; <repository> declares no releases: <reason> or could not be read: <refusal>; <repository> holds no commit <commit>: the history the repair was recorded in was rewritten or never reached this checkout; and <commit> is not in the history of <commit>, the commit <repository> stands on. Record the repair again at the commit that holds it (oko defects repaired <id> --revision <repository>@<commit>). A plan whose open repairs Oko cannot list is refused with Oko's error, never printed without this listing. A recorded repair that names no <repository>@<commit> cannot be carried by any commit, so while Oko holds one the plan refuses, a queue pass queues nothing and says why on stderr, and stado ci run refuses when it looks for the authors of a refused step: Oko records repairs that name no <repository>@<commit>, so no commit can be found to carry them: <defect> ("<record>"), …; record each with oko defects repaired ID --revision REPOSITORY@COMMIT. Stado Desktop's two operations take the same order in the "Products delivered first" field and show the same listing. Real journey: tests/release/delivery-queue-order.mjs.

stado release newest --register [--json] prints the queue's register as it stands, reading no checkout and running no step: per commit its state, the step it is on or that refused it with the step's error, the defects it carried and recorded, and — once a pass got there — released_at, when the release step published the release, and recorded_at, when Oko recorded it on the carried defects. A retried record keeps the publication time the earlier pass saw. JSON is {path, entries}, newest entry first; a register that is not one is refused naming its path. Oko's fleet report reads its release figures from here: a carried repair whose commit was delivered passed the queue, one whose commit failed names the step, and the time from a recorded repair to its release and to its recording come from these timestamps. Real journey: tests/release/newest/queue-register.mjs.