The gateway stack only builds on one laptop

[ecv]

What needs to happen

Every branch in the edge gateway stack from the controllers branch onward pins the shared network API to a sibling checkout on one developer's laptop instead of to a published version. Nothing outside that laptop can build.

CI is red on all six of those pull requests. Lint, Build, Unit Tests, Unit Tests (root), and every image publish job fail at module resolution. The failure is not scoped to the new gateway code. The whole module stops resolving, including packages that predate this work.

Two production container images inherited the same coupling. Both now expect the caller to hand them that sibling checkout as a named build context. The local lab passes it. The publish pipeline does not, so image builds break once this reaches the default branch.

The lab bring-up script reads the new custom resource definitions out of the sibling checkout as well, rather than from anything the repo or the cluster provides.

Why this matters

The stack is seven pull requests deep and every branch below the origin carries the same line by inheritance. Anyone who checks out one of these branches, or reviews it, or lets CI run on it, sees a failure that has nothing to do with the change under review. Real defects hide behind noise like that.

It also survives merge. The two images that now require the extra build context are the ones the publish pipeline pushes, so the first release after this lands produces nothing.

Desired outcome

1. Re-pin the network API dependency to a published version and delete the local path override and its comment block.
2. Remove the matching build-context requirement from both container images.
3. Let the lab bring-up install the new custom resource definitions from a published source rather than a sibling checkout.
4. Confirm the re-pin compiles against the upstream shape, since the override may have been masking drift.

The upstream types this override was waiting on have already landed on the network repository's default branch, so step one is unblocked today.

Found while reviewing #350 through #356.

[ecv]

Specifics, for whoever picks this up.

The line is go.mod:117 on feat/edge-gateway-03-controllers:

replace go.datum.net/network => ../network

main and feat/edge-gateway-02-engine are clean. -03 through -08 all carry it identically, purely by inheritance, which is why #350 is the only green PR in the stack.

Decisive CI line, byte-identical across all six failing PRs:

internal/cnibgp/bgp.go:37:2: go.datum.net/network@v0.0.0-20260731111530-4acc89aef817: replacement directory ../network does not exist

Note the file it names. That is pre-existing CNI code, nothing to do with the gateway, which is what makes this a whole-module failure rather than a scoped one. internal/cni, internal/gc and cmd/galactic-bgp all fail setup the same way.

The image side, added in #355:

• containers/galactic-router/Dockerfile and containers/galactic-gateway/Dockerfile both gained COPY --from=network . /network
• deploy/containerlab/Taskfile.yaml:44,51,58 pass --build-context network=../../../network for the router, gateway and CNI images
• .github/workflows/publish.yaml passes no build-contexts input to datum-cloud/actions/.github/workflows/publish-docker.yaml@v1.20.0, so the publish jobs fail inside the build at go mod download

The router Dockerfile's own comment already calls this out: callers that do not pass the context "must not hit this Dockerfile until the replace is removed". publish.yaml is such a caller.

Lab CRDs come from deploy/containerlab/scripts/deploy-system.sh:28:

NETWORK_SIBLING_CRD_DIR="${SCRIPT_DIR}/../../../../network/config/crd"

On the re-pin: datum-cloud/network's default branch already carries api/v1alpha1/gateway_types.go and api/v1alpha1/rule_types.go. The pinned pseudo-version here is from 2026-07-31 and predates them, so go get go.datum.net/network@main plus deleting the replace should be the whole change, modulo whatever drift the override was hiding.

[ecv]

@privateip flagging this one directly, since it gates the whole edge gateway stack rather than any single PR in it.

Every branch from feat/edge-gateway-03-controllers down carries the replace go.datum.net/network => ../network line, so CI is red on #351 through #356 and the failures point at pre-existing CNI code rather than at anything you changed. #350 was the only green one and it has landed.

The re-pin looks unblocked: datum-cloud/network's default branch already carries api/v1alpha1/gateway_types.go and api/v1alpha1/rule_types.go, and the version pinned here predates both.

Two things ride along with the replace when it goes, listed in the comment above: the COPY --from=network lines that #355 adds to the router and gateway Dockerfiles, and the sibling-checkout CRD path in the lab bring-up script. The router one matters most, since that image ships today and the publish pipeline passes no build context.

Happy to take this on if you'd rather not context-switch. Say the word and it's yours to review instead.

[ecv]

Resolved by @privateip. Verified across the whole stack.

main now pins go.datum.net/network v0.0.0-20260812184454-6e8a6c4cbd40 with no replace directive, and #351 is merged.

The four open branches are clean too. Checked each head directly: #352, #353, #354, #355 and #356 all carry the same pin and no override.

The image and lab coupling went with it. On #355's head there is no COPY --from=network in either the router or the gateway Dockerfile, no --build-context network= in the lab Taskfile, and no sibling-checkout CRD path in the bring-up script.

CI on #352 is green across Lint, Build, Unit Tests and Unit Tests (root), which is the first time anything in this stack above #350 has been.

I had a re-pin branch in flight to the same version; it is redundant and deleted.

Closing.