builder: consume package-registry as a real mesh grant, not a hand-faked one #61

2026-09-25T15:25:00Z

jschoubben commented

2026-09-25 15:25:00 +00:00

The package-binding resource was a hardcoded JSON fragment standing in for a real grant — {"provision": "package-registry", "from": "gitea", "at": "127.0.0.1", ...} written as if it were mesh-resolved, when nothing resolved it. Declares requires: package-registry properly instead, with binds/secrets pointing at the same file paths the resource used to manually author, so the mesh mints the grant and writes it there.

npm-password renamed to package-registry.secret: it's gitea's generic user+password, not npm-specific — the same credential works for basic auth against cargo/PyPI/Go package endpoints too, once gitea's manifest grows them (novox/hq ADR 0109).

Also qualifies builder's own image with its registry host (novox.internal:5100/mesh-builder@...) — a bare mesh-builder@sha256:... reference is only resolvable for a module with a build section, which builder doesn't have (it's handed over, not built), so nothing ever rewrote it and a push tried Docker Hub. Caused a brief live mesh-builder outage tonight, found and fixed within the same push.

Known gap, not fixed here (hq issue 117): this makes builder correct for the steady state but breaks a genesis bootstrap — gitea's own image is built by builder, so builder cannot yet hold this grant the first time either has to exist. Filed rather than silently accepted; the three TestTheBuildersCarriedPackageBinding* tests in mesh-controller are left failing on purpose to keep the gap visible.

Already built, pushed, and verified live on novox — real grant confirmed (as: mesh_novox_builder, real port), a real build round-tripped through it successfully after the fix.

The `package-binding` resource was a hardcoded JSON fragment standing in for a real grant — `{"provision": "package-registry", "from": "gitea", "at": "127.0.0.1", ...}` written as if it were mesh-resolved, when nothing resolved it. Declares `requires: package-registry` properly instead, with `binds`/`secrets` pointing at the same file paths the resource used to manually author, so the mesh mints the grant and writes it there. `npm-password` renamed to `package-registry.secret`: it's gitea's generic user+password, not npm-specific — the same credential works for basic auth against cargo/PyPI/Go package endpoints too, once gitea's manifest grows them (novox/hq ADR 0109). Also qualifies `builder`'s own image with its registry host (`novox.internal:5100/mesh-builder@...`) — a bare `mesh-builder@sha256:...` reference is only resolvable for a module with a `build` section, which `builder` doesn't have (it's handed over, not built), so nothing ever rewrote it and a push tried Docker Hub. Caused a brief live `mesh-builder` outage tonight, found and fixed within the same push. **Known gap, not fixed here (hq issue 117):** this makes `builder` correct for the steady state but breaks a genesis bootstrap — gitea's own image is built by `builder`, so `builder` cannot yet hold this grant the first time either has to exist. Filed rather than silently accepted; the three `TestTheBuildersCarriedPackageBinding*` tests in mesh-controller are left failing on purpose to keep the gap visible. Already built, pushed, and verified live on novox — real grant confirmed (`as: mesh_novox_builder`, real port), a real build round-tripped through it successfully after the fix.

jschoubben added 2 commits 2026-09-25 15:25:00 +00:00

builder: consume package-registry as a real mesh grant, not a hand-faked one 755b0a5599

The 'package-binding' resource was a hardcoded JSON fragment standing in
for a real grant — {"provision": "package-registry", "from": "gitea",
"at": "127.0.0.1", ...} written as if it were mesh-resolved, when nothing
resolved it. Declares requires: package-registry properly instead, with
binds/secrets pointing at the same file paths the resource used to
manually author, so the mesh mints the grant and writes it there.

npm-password renamed to package-registry.secret: it's gitea's generic
user+password, not npm-specific — the same credential works for basic
auth against cargo/PyPI/Go package endpoints too, once gitea's manifest
grows them (novox/hq ADR 0109).

Known gap, not fixed here (novox/hq issue 117): this makes builder
correct for the steady state but breaks a genesis bootstrap — gitea's own
image is built by builder, so builder cannot yet hold this grant the
first time either has to exist. Filed rather than silently accepted.

builder: qualify its own image with the registry host 1b02dc1f66

Bare mesh-builder@sha256:... is only resolvable for a module with a build
section — the mesh's own build step rewrites the reference to a real
registry path as part of resolving build.artifacts. builder is handed
over, not built, so nothing ever rewrites it: pushed as written, docker
read it literally and tried Docker Hub. Took the live node's mesh-builder
down for the length of one push-and-fix (docker: pull access denied for
mesh-builder, repository does not exist). novox.internal:5100, not the
literal external IP docker inspect showed live, for the same reason
addresses generally don't get hardcoded in this catalogue.

jschoubben merged commit 271911753f into main

2026-09-25 15:25:05 +00:00

jschoubben deleted branch fix/builder-real-package-registry-grant

2026-09-25 15:25:05 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-catalog#61