Issue 186: a release across repositories is an order in a person's head, and a build is a line in a queue nobody keeps #254
+51
@@ -0,0 +1,51 @@
|
||||
---
|
||||
status: open
|
||||
opened: 2026-10-01
|
||||
located-in: []
|
||||
fixed-by:
|
||||
amended-design: []
|
||||
---
|
||||
|
||||
# 186 — A release across repositories is an order in a person's head, and a build is a line in a queue nobody keeps
|
||||
|
||||
## What was observed
|
||||
|
||||
On 2026-10-01 one decision (ADR 0161) was built as three pull requests in three repositories that
|
||||
must land in order: the controller first, so the seat exists and a report's profile is kept; the host
|
||||
second, so every machine reports the capability; the catalogue last, so a claim names a seat that
|
||||
exists and a holder is not refused on every machine. That order is written in a work-order file and
|
||||
in the pull requests' descriptions. The mesh holds none of it. A merge is handled as a merge: build
|
||||
the modules whose recorded source is that repository, record what came back. Nothing says what the
|
||||
mesh should end up as, and nothing checks whether it got there.
|
||||
|
||||
The same day showed what a build is. The build machine takes asks from an in-memory queue; when it
|
||||
was itself rebuilt in the middle of a wave of forty-three asks, the machine rolled, the new one
|
||||
started with an empty queue, and forty asks were gone without a word — the wave read "one of
|
||||
forty-three" for two hours. A merge announcement that asks forty builds waits for them inside the
|
||||
controller's one receive loop ([issue 184](../184-a-merge-announcement-blocks-the-controllers-receive-loop/00-report.md)).
|
||||
"Did everything I asked for succeed" was answered by counting lines in two containers' logs.
|
||||
|
||||
## Why this is here
|
||||
|
||||
Every single step is sound: a build is reproducible, a push composes a machine from the store as it
|
||||
is, memberships are last-per-subject, so the mesh converges to the right state once every build is
|
||||
recorded and every machine pushed. What is missing is the whole: the mesh has no durable account of
|
||||
work it has asked for and no account of the state a release is aiming at, so the two faults that
|
||||
matter most to an operator — work silently lost, and a dependency between repositories merged in
|
||||
the wrong order — are detected by nobody. The rule that a manifest word ships one release ahead of
|
||||
its use is a discipline a person keeps, and a person kept it by hand eleven times this week.
|
||||
|
||||
## What a decision would settle
|
||||
|
||||
- Whether a build ask is a durable message on the bus (a work queue the build machine takes from and
|
||||
acknowledges, as the build outcome already is an event), so a restarted builder resumes rather
|
||||
than forgets, and `builds` can list what is asked and not yet built.
|
||||
- Whether a release across repositories is a thing the mesh records — a set of commits that belong
|
||||
together with the order they land in — so that a merge out of order is refused or held rather than
|
||||
built, and `status` can say what a release still waits for.
|
||||
- What the smallest honest surface is in the meantime: at least `builds` listing the asked and the
|
||||
running beside the built, so a person polling logs becomes a person reading one table.
|
||||
|
||||
*How this would be checked:* a builder restarted between an ask and its build still builds it; a
|
||||
merge of a dependent repository before its prerequisite is held and named; `builds` lists asked,
|
||||
running and built.
|
||||
Reference in New Issue
Block a user