24 lines
1.8 KiB
Markdown
24 lines
1.8 KiB
Markdown
# Diagnosis — 2026-09-21
|
|
|
|
1. The package half was read against what the mesh now runs. The mesh's package registry has
|
|
proxied the public one for every package since early September, before this issue was opened;
|
|
and the builder's `.npmrc` names the mesh's registry for the mesh's own scope only, so a public
|
|
package is asked of the public registry directly. Either the failing build ran before the
|
|
proxy, or its Dockerfile set the registry itself, or the build machine could not reach the
|
|
public registry at that moment. The report does not say which, and the 404 cannot be placed
|
|
without running the build again. Not fixed; not reproduced either.
|
|
2. The image half has a precedent. The lab hit the same refusal pulling a vendor tool and found
|
|
the cause was the public hub denying anonymous pulls, not the mesh's redirect; the fix was to
|
|
pin the same image from another registry. A `COPY --from` of a public image is a build input
|
|
the manifest does not declare, so the mesh cannot pre-fetch or pin it the way it pins bases —
|
|
which is the second open question, and the one a decision has to settle.
|
|
3. Ruled out: that the build environment has no internet. Package installs from the system's
|
|
repositories succeed in the same Dockerfiles.
|
|
|
|
**Located in:** the builder (what it tells npm and the runtime) and the catalogue (three modules
|
|
whose Dockerfiles fetch what no manifest names). The image half is decided and built:
|
|
[ADR 0097](../../02-DECISIONS/0097-a-vendor-image-is-a-declared-build-input.md) — a vendor image
|
|
is declared under `build.on`, copied in, and a recipe fetching what is undeclared is refused. Still
|
|
open: the package half — a build must be re-run against the mesh's proxying registry to place the
|
|
404 — and the three recipes themselves, which now declare their images or are refused.
|