A build service that uses the mirrors
Keeping a mirror stocked usually means somebody maintaining a list of what to mirror, and that list is wrong the moment a dependency changes. The build service closes the loop instead: if your builds resolve through the mirror, the mirror necessarily ends up holding everything they needed — and nobody had to write it down.
Runners poll out
A coordinator holds the queue and runners poll it, rather than the coordinator pushing work out. That one choice is why a build host needs NO inbound ports at all, which in turn is what makes it reasonable to run one on a laptop, behind NAT, or on a machine whose firewall is not yours to change.
Scheduling is by label: a target declares what it requires, and a runner is only leased work whose requirements are a subset of what it advertises. An empty requirement runs anywhere.
Recipes live in the repo as world-build.json, so the build definition is versioned with the thing it builds.
Hermetic by construction
Source is checked out through the git backend and every dependency resolves through the mirrors. So the build is reproducible for the same reason the mirror stays current: both follow from the same routing, and neither needs maintaining separately.
Steps can be cached — the target declares which directories to persist and, optionally, the files whose contents key the cache.
What it costs
Stated plainly, because a claim with no stated cost is the one nobody re-checks.
Cancel lands only at step boundaries. The live log ring is in-memory, though the full log is always uploaded as an artifact. Dependency attribution is time-window-based rather than exact.
A restored step cache carries the workspace it was packed in. Most caches do not care where they live; one that bakes absolute paths (a libtool RUNPATH, a pkg-config prefix, a CMake cache) does, and the runner warns naming what still holds the old path.