Send image artifacts to mesh-build-image, one node, publishing only from the trunk (issue 1705) #20

Merged
mesh-tools merged 3 commits from feat/r4c9-image-build into main 2026-10-22 08:57:21 +00:00
Member

Part of design 47's milestone R4c-9 (ADR 0487): the image build module. A container image becomes one more artifact kind the builder builds through a build module, like Go and Node: mesh-build-image builds rootless with buildah, a candidate's check publishes nothing, a trunk build publishes exactly one digest and its build key names the reference. build-agent keeps building and delivering every image until R4g; nothing the operator sees changes. One delivery group on branch feat/r4c9-image-build in mesh-catalog and mesh-delivery. After the delivery the lead assigns buildah and mesh-build-image to shanks and ace.

Said with the Approve: an image build on a build node has no CPU or memory limit yet, like the other build modules (issue 1806); the builder's capacity bounds how many run. Until the operator answers whether R4g waits only for images that outlive it, mesh-build-image refuses an image whose build input is a whole repository or whose build argument is another module's artifact, naming why (only build-agent's and the toolchain images use those forms, and R4g deletes them).

Review: one review, three rounds, approved (reviewer-r4c9@shanks). The real-buildah integration tests skip loudly where the check has no buildah; ADR 0487 §2 and §6 are proved live after the delivery.

This member (1705): the builder sends image artifacts to mesh-build-image on one node chosen from node-engine.have; a candidate never publishes; a trunk key whose image was built only as a candidate is published once, and a failed publish is written to the key; a second Go node rebuilds only its own work; with no node running mesh-build-image the key fails naming rootless-image-build and is retaken only on a change. Its tests read mesh-build-image's captured fixtures.

Reviewed-by: reviewer-r4c9@shanks at db62e82e26

Part of design 47's milestone R4c-9 (ADR 0487): the image build module. A container image becomes one more artifact kind the builder builds through a build module, like Go and Node: mesh-build-image builds rootless with buildah, a candidate's check publishes nothing, a trunk build publishes exactly one digest and its build key names the reference. build-agent keeps building and delivering every image until R4g; nothing the operator sees changes. One delivery group on branch `feat/r4c9-image-build` in mesh-catalog and mesh-delivery. After the delivery the lead assigns buildah and mesh-build-image to shanks and ace. Said with the Approve: an image build on a build node has no CPU or memory limit yet, like the other build modules (issue 1806); the builder's capacity bounds how many run. Until the operator answers whether R4g waits only for images that outlive it, mesh-build-image refuses an image whose build input is a whole repository or whose build argument is another module's artifact, naming why (only build-agent's and the toolchain images use those forms, and R4g deletes them). Review: one review, three rounds, approved (reviewer-r4c9@shanks). The real-buildah integration tests skip loudly where the check has no buildah; ADR 0487 §2 and §6 are proved live after the delivery. This member (1705): the builder sends image artifacts to mesh-build-image on one node chosen from node-engine.have; a candidate never publishes; a trunk key whose image was built only as a candidate is published once, and a failed publish is written to the key; a second Go node rebuilds only its own work; with no node running mesh-build-image the key fails naming rootless-image-build and is retaken only on a change. Its tests read mesh-build-image's captured fixtures. Reviewed-by: reviewer-r4c9@shanks at db62e82e26d7f3423d115b9fe6739437cae6c007
mesh-tools added 3 commits 2026-10-22 08:47:10 +00:00
Write a failed publish of a merged image to the key; read mesh-build-image's captured steps (review r2)
mesh/repo-check head db62e82e26d7 merged into trunk 47ab8cd3cf45 beside mesh-catalog#435@7c5d11e5 — pass: its merge-check.sh passed
mesh/merge-gate head db62e82e26d7 merged into trunk 47ab8cd3cf45 — pass: group feat/r4c9-image-build composed: every machine composes with the change as it…
mesh/check pass db62e82e26d7 on 2b635e2138ae | unit 366 run 0 kept | int 405 run 0 kept | clone 9.2s unit 191ms int 6.7s+44s | composition not yet run
mesh/delivery delivered
mesh/delivery-group group feat/r4c9-image-build delivered: every member is delivered
db62e82e26
Author
Member

Delivery novox/mesh-delivery@db62e82e26d7 — delivered since 2026-10-22T09:02:24Z

Delivery plan — builds mesh-delivery-builder → novox; no bus step

  • tier 0: mesh-delivery-builder
  • novox: receives mesh-delivery-builder

Group feat/r4c9-image-build: novox/mesh-catalog@7b5f7f84ac, novox/mesh-delivery@db62e82e26

  • composed together: pass — every machine composes with the change as it did without (4 of 4 compose)

Machines

  • gitea on every machine running it: sent
  • mesh-delivery-builder on every machine running it: sent
  • mesh-issues on every machine running it: sent

Transitions

  • 2026-10-22 08:47 (new) → proposed (announced): novox/mesh-delivery#20's head announced
  • 2026-10-22 08:48 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit
  • 2026-10-22 08:48 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail
  • 2026-10-22 08:59 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move
  • 2026-10-22 08:59 published → delivering (go): its walk started: let go by this owner in its group's order, by a person, or on the controller's own path — not a failed walk that carried a later commit for it, after which it waits for a walk of its own commit
  • 2026-10-22 09:02 delivering → delivered (done): its walk is done, carrying its own commit: every machine of its deploy plan passed, or was left as its policy says

The commit's note under refs/notes/mesh-plan keeps every transition: git log --notes=mesh-plan.

<!-- mesh-delivery:view --> **Delivery** `novox/mesh-delivery@db62e82e26d7` — **delivered** since 2026-10-22T09:02:24Z **Delivery plan** — builds mesh-delivery-builder → novox; no bus step - tier 0: mesh-delivery-builder - novox: receives mesh-delivery-builder **Group** `feat/r4c9-image-build`: novox/mesh-catalog@7b5f7f84acb7, novox/mesh-delivery@db62e82e26d7 - composed together: pass — every machine composes with the change as it did without (4 of 4 compose) **Machines** - gitea on every machine running it: sent - mesh-delivery-builder on every machine running it: sent - mesh-issues on every machine running it: sent **Transitions** - 2026-10-22 08:47 (new) → proposed (announced): novox/mesh-delivery#20's head announced - 2026-10-22 08:48 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit - 2026-10-22 08:48 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail - 2026-10-22 08:59 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move - 2026-10-22 08:59 published → delivering (go): its walk started: let go by this owner in its group's order, by a person, or on the controller's own path — not a failed walk that carried a later commit for it, after which it waits for a walk of its own commit - 2026-10-22 09:02 delivering → delivered (done): its walk is done, carrying its own commit: every machine of its deploy plan passed, or was left as its policy says The commit's note under `refs/notes/mesh-plan` keeps every transition: `git log --notes=mesh-plan`.
mesh-tools merged commit 2b635e2138 into main 2026-10-22 08:57:21 +00:00
mesh-tools deleted branch feat/r4c9-image-build 2026-10-22 08:57:22 +00:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: novox/mesh-delivery#20