An image artifact may name its own build context, apart from the module's repository #62

2026-09-25T15:39:36Z

jschoubben commented

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

route-proxy's own Dockerfile documents the shape it has always needed and never had: "the proxy source is not vendored here... the build context is the mesh-controller repository root, and this Dockerfile compiles ./examples/route-proxy from it." Nothing in the mesh could do that — the build command clones one repository and builds every artifact from within it, so route-proxy has never once been built through the pipeline, consistent with it never having been assigned anywhere.

Found attempting exactly that build tonight: stat go.mod: file does not exist, because the context was mesh-catalog, which does not have one.

An image artifact may now carry a context: {repository, ref}, cloned fresh alongside the module's own tree. The recipe (Dockerfile) is still read from the module's own directory, at the module's own commit — only docker build's own context argument moves. Packaging and source stay exactly as separate as route-proxy's own comment already said they were, now for real.

Full suite passes except the three pre-existing TestTheBuildersCarriedPackageBinding* failures (hq issue 117, unrelated, left failing on purpose).

route-proxy's own Dockerfile documents the shape it has always needed and never had: "the proxy source is not vendored here... the build context is the mesh-controller repository root, and this Dockerfile compiles ./examples/route-proxy from it." Nothing in the mesh could do that — the build command clones one repository and builds every artifact from within it, so route-proxy has never once been built through the pipeline, consistent with it never having been assigned anywhere. Found attempting exactly that build tonight: `stat go.mod: file does not exist`, because the context was mesh-catalog, which does not have one. An image artifact may now carry a `context: {repository, ref}`, cloned fresh alongside the module's own tree. The recipe (Dockerfile) is still read from the module's own directory, at the module's own commit — only `docker build`'s own context argument moves. Packaging and source stay exactly as separate as route-proxy's own comment already said they were, now for real. Full suite passes except the three pre-existing `TestTheBuildersCarriedPackageBinding*` failures (hq issue 117, unrelated, left failing on purpose).

jschoubben added 1 commit 2026-09-25 15:39:37 +00:00

an image artifact may name its own build context, apart from the module's repository 20e57c3f51

route-proxy's own Dockerfile documents the shape it has always needed and
never had: 'the proxy source is not vendored here... the build context is
the mesh-controller repository root, and this Dockerfile compiles
./examples/route-proxy from it.' Nothing in the mesh could do that — the
build command clones one repository and builds every artifact from
within it, so route-proxy has never once been built through the pipeline,
consistent with it never having been assigned anywhere. Found attempting
exactly that build tonight: 'stat go.mod: file does not exist', because
the context was mesh-catalog, which does not have one.

An image artifact may now carry a context: {repository, ref}, cloned
fresh alongside the module's own tree. The recipe (Dockerfile) is still
read from the module's own directory, at the module's own commit — only
docker build's own context argument moves. Packaging and source stay
exactly as separate as route-proxy's own comment already said they were,
now for real.

jschoubben merged commit 7ffe6ce21b into main

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

jschoubben deleted branch feat/an-artifact-may-name-its-own-build-context

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

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-controller#62