5.5 KiB
layer, status, code, updated, decisions
| layer | status | code | updated | decisions | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| as-is | implemented |
|
2026-10-17 |
|
Delivery — from a merge to the nodes, as it runs
What runs on the mesh's main branches on 2026-10-16, read from the code and the live record by research 055 (findings 1 to 12). It is what to-be 47 replaces, milestone by milestone. Until 2026-10-16 this document described the predecessor's pipeline, which no longer runs.
Who does what
- mesh-delivery owns deliveries and delivery groups (ADR 0239): one delivery per commit, a group per branch
name shared across repositories. It records each transition in its state on the bus (key-value buckets
deliveriesandgroups), marks pull requests, asks the controller to deliver, and merges a pull request marked ready at its head once both required checks pass against the trunk's head (ADR 0364) and the operator approved the merge into main on a channel that proves who answered (ADR 0398 §3). - The controller plans, orders, sends and judges. It computes a delivery plan for a repository and the files a merge changes, moves only modules whose build source changed with their build dependents (ADR 0267), and reuses a merge check's build of the same reuse key (ADR 0350).
- The builders (holders of the build seat) take build requests and checks from a work-queue stream on the bus and build inside a toolchain image another module provides, with the network off; on 2026-10-13 no node had Go or npm installed (issue 626).
- The forge module publishes every forge event on the bus through the forge's system webhook since 2026-10-14 (issue 729), and still polls the forge every 30 s, or every 300 s once it hears events. It keeps files of what it announced so it does not announce twice.
From a merge to a rollout
- The merge window. The controller collects merges into an open batch; each merge restarts the window, which closes after 90 seconds without a merge or 10 minutes after the batch's first merge (ADR 0276). A lone merge is cut at once (ADR 0282 §2, as ADR 0304 §1 changed it). The batch and its merges are rows in the controller's store, cut by a timer every 5 s, with a catch-up timer every 5 minutes for merges no batch holds.
- The rollout. A closed batch becomes one rollout, at most one commit per repository, tiered along the module graph. Rollouts run one at a time: a batch cut while a rollout is open is queued behind it, whatever it shares with it. Running unrelated rollouts side by side (ADR 0282 §3, ADR 0304 §2) is decided and not built (issue 525). A rollout's builds go to every machine at once, with no first-machine gate, and the rollout ends on the machines' reports or after fifteen minutes of silence (ADR 0360). A controller timer advances rollouts every 30 s.
- A merge during a rollout. Its place in the next batch is a store row the open rollout's holder writes. On 2026-10-16, when another controller worked the plans, a merge was not recorded and waited until a person released it (issue 921).
- "Release branches". A pull request into a branch other than a trunk is judged by the controller built from that branch (ADR 0358); feature 57 shipped about 37 packages that way over about 2.5 days and held the controller for 55.7 h.
Checks
- Every pull request's head gets
mesh/merge-gate(the composed machines) andmesh/repo-check(the repository'smerge-check.sh), each judged against one trunk commit (ADR 0323). A trunk move asks the check of every active, cleanly merging pull request again (ADR 0395). - A delivery group's members are each checked beside their siblings' heads, and the group also gets a composed
check,
mesh/delivery-group; each member keeps its own gate beside it (ADR 0382). - The queue's order (delivery builds first, then ready checks, then the rest) is kept by pausing the worker and deleting and republishing a request (issue 558); an old head's check is ended after asking the forge for the current head (issue 726).
- mesh-delivery ticks every 10 s, reconciles with the controller every 30 s and polls the forge for ready marks every minute, although the forge module already publishes labeled, commented and synchronized events.
Where the record of what runs lives
Builds and build requests, rollouts with their tiers, batches and merges, and assignments are rows in the controller's store; artifacts are blobs in the artifact store by digest (ADR 0251); packages are versions in the package registry. The controller writes three record mirrors to the bus: assignments, declared config and predefined keys; of the five ADR 0289 §7 decided, the nodes, rollouts, builds and settings mirrors are not in the code. An assignment names its module and node but not the build, artifact or rollout that put it there: which commit runs where, and which delivery brought it, takes three verbs and a join by hand.
No backup is taken before a delivery moves a module that holds data; backups run nightly and on demand (ADR 0214).
What is not covered
The integration tests run only in each repository's merge check; there are no end-to-end tests of delivery yet, and the lab is not used (the operator, 2026-10-16).