21 lines
1.5 KiB
Markdown
21 lines
1.5 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). Still open: a build must be re-run to place the
|
|
404, and a decision is needed on whether a vendor image is declared as a build input.
|