52 lines
3.0 KiB
Markdown
52 lines
3.0 KiB
Markdown
---
|
|
status: resolved
|
|
opened: 2026-09-18
|
|
located-in:
|
|
- mesh-catalog
|
|
- mesh-controller
|
|
fixed-by: ADR 0097 and mesh-controller #38 (a vendor image is a declared build input; a recipe copying out of an undeclared image is refused); the package half by the facts on current code — the one recipe that installs a public package (the catalogue module, pg) built and installed through the mesh's builder in the genesis bed on 2026-09-21, and no recipe copies from a public image any more
|
|
amended-design: 03-DESIGN/01-to-be/18-building-a-module.md
|
|
---
|
|
|
|
# 064 — A mesh build cannot fetch a module's external dependencies
|
|
|
|
## Symptom
|
|
|
|
Three modules cannot be built by the mesh's own builder, each because the build needs an artifact
|
|
from a public registry the build environment does not reach:
|
|
|
|
- A module whose runtime installs an npm package its code imports (`npm install` in the
|
|
Dockerfile) fails with a 404 — the build's npm is pointed at the mesh's own registry, which does
|
|
not carry the public package.
|
|
- A module whose runtime copies a binary out of a public image (`COPY --from=vendor/tool:latest`)
|
|
fails with `pull access denied` — the build's container runtime reaches the mesh's registry, not
|
|
the public one.
|
|
|
|
apt-based installs in the same Dockerfiles succeed, so the build has ordinary internet: it is npm
|
|
and image pulls specifically that are redirected to the mesh's registry. Observed while giving the
|
|
catalogue its build sections (hq issue 060): 44 of 70 modules build from their own source with no
|
|
external fetch; these three need one and stop.
|
|
|
|
## Why it matters beyond the instance
|
|
|
|
The delivery design says a module is built by the mesh from a repository and a path (ADR 0069),
|
|
compiled against the sdk and tool runtime the base images already carry. That holds for a module
|
|
whose only dependencies are the base's — but a module with a third-party runtime dependency, or a
|
|
tool binary from a vendor image, has no sanctioned way to bring it into a mesh build. The
|
|
workstation build script got away with it by running on a host with public npm and Docker Hub;
|
|
retiring that shortcut (the no-fake principle) exposes that the mesh has no answer.
|
|
|
|
Left unanswered, "the mesh builds its own catalogue" is true only for modules that happen to have
|
|
no external dependency, and which those are is invisible until each is built.
|
|
|
|
## Open questions
|
|
|
|
- Should a module's third-party npm dependencies be published to the mesh's own registry as part
|
|
of building it (a dependency is an artifact like any other), or should the build environment
|
|
proxy the public registry read-only?
|
|
- Is a vendor binary (`mc`, and others like it) the same question as an npm dependency, or does it
|
|
want a distinct answer — a module declaring an external image as a build input the mesh
|
|
pre-fetches and pins, the way it pins its bases?
|
|
- Should a manifest that declares a build whose Dockerfile fetches from a public registry be
|
|
refused at `module add`, so the gap is caught at registration rather than at build?
|