Files
mesh-catalog/modules/mesh-build-image
jschoubben 9e2d1164f0
mesh/merge-gate head 9e2d1164f06e merged into trunk 5a6d082e8c55 — pass: builds mesh-build-image, sent nowhere; no bus step; every machine composes with th…
mesh/repo-check head 9e2d1164f06e merged into trunk 5a6d082e8c55 — pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (go), merge-…
mesh/delivery delivered
mesh/check failed: unit: modules/gitea.test: [gitea] where the poll of merges last looked from could not be read, so none is kept — no runtime | 9e2d1…
Give mesh-build-image the registry's address as the seat's reach, which the provisioner's client fills (issue 1703)
2026-10-22 11:07:50 +02:00
..

mesh-build-image — the image build module

Design 47, release R4c-9 (novox/hq ADR 0487, ADR 0466 §1, ADR 0469; issue 1703). The module that builds a module's image artifact from the Dockerfile in the module's own directory, on a build machine, as an account of its own (runs-as, no login shell, home at mode 0700). It serves every module's image, whatever the base, so it is not a build module for one module. It claims no seat: it is assigned to the build machines and runs dark until the builder uses it.

Rootless

The tool is buildah, which the buildah module installs and provides as rootless-image-build with the machine's reach: a machine without it refuses this module at assignment, naming buildah. The build runs as the module's own account in a user namespace (--isolation oci), with buildah's image store and runtime state in /var/lib/mesh-build-image-store (outside the home), no mount of the host, no container runtime socket, no registry credential and an environment built from scratch.

The account's subordinate user and group ranges are not declared anywhere: the node-engine makes every user account with useradd, which allocates them. The module's health reads /etc/subuid and /etc/subgid and is unhealthy without a range for the account, without buildah, or when a user namespace cannot be made.

The Dockerfile's steps may use the network (ADR 0487 §6); nothing a step can read holds a key.

Steps

  • build_image_fetch fetches a commit over SSH into a workspace (a base commit makes the merge preview, as the other build modules' fetch). Long: answers a step id and ends on its key in steps.
  • build_image_build builds one image artifact: buildah bud with the Dockerfile of the module's directory as file and context, --target, and the images build.on pins as --build-arg. Answers the image's digest. With publish: true (a merged trunk commit only) the module's own process then pushes it to the registry under <module>/<artifact>:<tag of its own> (the first 12 hex digits of the digest unless the call gives one), waiting out a registry held still, and the key carries the digest the registry serves and the reference pinned by it. Without publish (a pull request) nothing is pushed.
  • It refuses, naming why, an image whose build context is a whole repository (context) or whose build.on names another module's artifact (unsupportedImage in build.go): those forms belong to the images build-agent builds until it is removed at R4g.
  • build_image_step, build_image_steps, build_image_status and build_image_health read.

The registry's address is placed into <home>/registry as ${seat:mesh-artifact-store:reach} (host:port): the provisioner's client fills a moved module's placement, and the artifact store has not moved, so a ${bound:artifact-store:...} is refused at composition (issue 1703).