Build the Go toolchain at genesis's base step, beside the base (issue 616) #106

2026-10-13T09:14:18Z

mesh-admin commented

2026-10-13 09:14:18 +00:00

Issue 616 (genesis stops at step 17: postgres's Go code needs mesh-tools-go, and the mesh holds no copy of it).

Cause: BuildBase built only --tools-source (mesh-tools, the TypeScript toolchain). Bundles compile in their language's base (mesh-controller internal/builder toolchain.go), and genesis's own modules include Go bundles: postgres code, and nats tools. gitea, which is an extra, has two more.

Fix: the base step builds mesh-tools, then mesh-tools-go. mesh-tools-go comes from the new --tools-go-source/--tools-go-ref; without the flag it is the repository beside --tools-source named mesh-tools-go, as the mesh keeps it. A base not named mesh-tools, with no flag, is refused naming the flag. genesisToolchains names the pairs. The usage text names the flags.

Tests

TestTheBaseStepBuildsEveryToolchainAGenesisModuleIsCompiledIn reads the real catalogue (MESH_CHECK_BESIDE / beside / loud skip). For registry, build-agent, postgres, nats, mesh-vault, mesh-catalog and nftables, every bundle's language must have a toolchain the base step builds. Image artifacts build on their own pinned bases.
TestTheBaseStepBuildsTheGoToolchainBesideTheBase fails on main, which builds only mesh-tools.
TestTheGoToolchainIsAsGivenOrBesideTheBase.
gofmt, vet and go test ./... pass, run niced without -race as asked.

Lab: the bed's forge must serve mesh-tools-go too. That is mesh-lab's PR for issue 616.

Fixes issue 616.

Issue 616 (genesis stops at step 17: postgres's Go code needs mesh-tools-go, and the mesh holds no copy of it). **Cause**: `BuildBase` built only `--tools-source` (mesh-tools, the TypeScript toolchain). Bundles compile in their language's base (mesh-controller internal/builder toolchain.go), and genesis's own modules include Go bundles: postgres `code`, and nats `tools`. gitea, which is an extra, has two more. **Fix**: the base step builds mesh-tools, then mesh-tools-go. mesh-tools-go comes from the new `--tools-go-source`/`--tools-go-ref`; without the flag it is the repository beside `--tools-source` named mesh-tools-go, as the mesh keeps it. A base not named mesh-tools, with no flag, is refused naming the flag. `genesisToolchains` names the pairs. The usage text names the flags. **Tests** - `TestTheBaseStepBuildsEveryToolchainAGenesisModuleIsCompiledIn` reads the real catalogue (MESH_CHECK_BESIDE / beside / loud skip). For registry, build-agent, postgres, nats, mesh-vault, mesh-catalog and nftables, every bundle's language must have a toolchain the base step builds. Image artifacts build on their own pinned bases. - `TestTheBaseStepBuildsTheGoToolchainBesideTheBase` fails on main, which builds only mesh-tools. - `TestTheGoToolchainIsAsGivenOrBesideTheBase`. - gofmt, vet and `go test ./...` pass, run niced without -race as asked. **Lab**: the bed's forge must serve mesh-tools-go too. That is mesh-lab's PR for issue 616. Fixes issue 616.

mesh-admin added 1 commit 2026-10-13 09:14:18 +00:00

Build the Go toolchain at genesis's base step, beside the base (hq issue 616)

mesh/merge-gate head 8108dd5c23c6 merged into trunk f0d39b4a4ab0 — pass: the change touches no module of the mesh's graph

Details

mesh/repo-check head 8108dd5c23c6 merged into trunk f0d39b4a4ab0 — pass: its merge-check.sh passed

Details

mesh/delivery delivered

Details

8108dd5c23

Genesis's base step built only mesh-tools, the TypeScript toolchain. The store's and the bus's modules
carry Go bundles, compiled in mesh-tools-go, so genesis stopped at the store step: "this mesh holds no
copy of it. Build mesh-tools-go first". The base step now builds mesh-tools-go too, from
--tools-go-source or the repository beside --tools-source, and a test holds every toolchain a genesis
module's bundles compile in, read from the catalogue, to the ones the step builds.

mesh-admin commented

2026-10-13 09:14:27 +00:00

Delivery novox/mesh-host@8108dd5c23c6 — delivered since 2026-10-13T09:23:35Z

Delivery plan — builds nothing: the change touches no module of the mesh's graph

Transitions

2026-10-13 09:14 (new) → proposed (announced): novox/mesh-host#106's head announced
2026-10-13 09:15 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit
2026-10-13 09:15 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail
2026-10-13 09:23 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move
2026-10-13 09:23 published → delivered (done): nothing for a walk to move

The commit's note under refs/notes/mesh-plan keeps every transition: git log --notes=mesh-plan.

**Delivery** `novox/mesh-host@8108dd5c23c6` — **delivered** since 2026-10-13T09:23:35Z **Delivery plan** — builds nothing: the change touches no module of the mesh's graph **Transitions** - 2026-10-13 09:14 (new) → proposed (announced): novox/mesh-host#106's head announced - 2026-10-13 09:15 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit - 2026-10-13 09:15 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail - 2026-10-13 09:23 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move - 2026-10-13 09:23 published → delivered (done): nothing for a walk to move The commit's note under `refs/notes/mesh-plan` keeps every transition: `git log --notes=mesh-plan`.

mesh-admin reviewed

2026-10-13 09:22:38 +00:00

mesh-admin left a comment

Verdict: approve at 8108dd5c23

The default (no --tools-go-source) is safe when the beside repository does not exist. toolsGoSource refuses by name when --tools-source is not itself named mesh-tools, asking for --tools-go-source explicitly. When it is named mesh-tools, the computed mesh-tools-go repository flows straight into BuildBase's say() line and into controlPlane.tell()'s wrapped error (internal/bootstrap/talk.go: "<container> build <repo> --ref ... --wait 1200s was refused: \n"), so a beside repository that does not exist fails loudly, naming the exact repository it tried, not a silent skip.

I could not make the new test literally fail on main. Copying internal/bootstrap/genesis_toolchains_test.go alone onto origin/main (f0d39b4a4a) does not compile, because main has none of genesisToolchains, toolsGoSource, or Options.ToolsGoSource — all three are introduced by this same PR. So the PR body's phrase "fails on main" is imprecise: the test cannot run against main at all, pass or fail, without the rest of this PR's source changes. I did independently confirm the claim is true in spirit: main's BuildBase (internal/bootstrap/phase2.go) issues exactly one build call, for --tools-source only, which is the behaviour the issue reports. This is a wording nit, not a reason to block.

I cross-checked TestTheBaseStepBuildsEveryToolchainAGenesisModuleIsCompiledIn against the real catalogue (cloned beside, via MESH_CHECK_BESIDE): postgres's "code" bundle and nats's "tools" bundle are both go, the only two genesis bundles that are not typescript, exactly matching genesisToolchains and the issue's own symptom. mesh-controller is rightly left out of genesisModules, since it is carried and pinned at genesis rather than built fresh from the base.

go vet ./... is clean, gofmt -l . lists nothing, and the full suite (go test -count=1 ./...) passes completely — mesh-catalog and mesh-controller were cloned beside mesh-host so the catalogue- and controller-reading tests ran for real rather than skipping — including the three new tests and the whole pre-existing suite. All of this ran as nice -n 15 with GOFLAGS=-p=2 GOMAXPROCS=4 and CGO_ENABLED=0 (no -race, as asked, since g14 is overloaded).

I ran merge-check.sh's own three steps by hand with the race detector intentionally left out (gofmt, go vet, go test -count=1 ./...), since this environment has gcc and the script would otherwise have picked -race: all three pass. The PR head's own statuses already say so: mesh/merge-gate reports "head 8108dd5c23 merged into trunk f0d39b4a4a — pass: the change touches no module of the mesh's graph" and mesh/repo-check reports "head 8108dd5c23 merged into trunk f0d39b4a4a — pass: its merge-check.sh passed".

Verdict: approve at 8108dd5c23c6a94bedeb6e169014061faaa71f72 The default (no --tools-go-source) is safe when the beside repository does not exist. toolsGoSource refuses by name when --tools-source is not itself named mesh-tools, asking for --tools-go-source explicitly. When it is named mesh-tools, the computed mesh-tools-go repository flows straight into BuildBase's say() line and into controlPlane.tell()'s wrapped error (internal/bootstrap/talk.go: "`<container> build <repo> --ref ... --wait 1200s` was refused: <err>\n<output>"), so a beside repository that does not exist fails loudly, naming the exact repository it tried, not a silent skip. I could not make the new test literally fail on main. Copying internal/bootstrap/genesis_toolchains_test.go alone onto origin/main (f0d39b4a4ab0) does not compile, because main has none of genesisToolchains, toolsGoSource, or Options.ToolsGoSource — all three are introduced by this same PR. So the PR body's phrase "fails on main" is imprecise: the test cannot run against main at all, pass or fail, without the rest of this PR's source changes. I did independently confirm the claim is true in spirit: main's BuildBase (internal/bootstrap/phase2.go) issues exactly one build call, for --tools-source only, which is the behaviour the issue reports. This is a wording nit, not a reason to block. I cross-checked TestTheBaseStepBuildsEveryToolchainAGenesisModuleIsCompiledIn against the real catalogue (cloned beside, via MESH_CHECK_BESIDE): postgres's "code" bundle and nats's "tools" bundle are both go, the only two genesis bundles that are not typescript, exactly matching genesisToolchains and the issue's own symptom. mesh-controller is rightly left out of genesisModules, since it is carried and pinned at genesis rather than built fresh from the base. go vet ./... is clean, gofmt -l . lists nothing, and the full suite (go test -count=1 ./...) passes completely — mesh-catalog and mesh-controller were cloned beside mesh-host so the catalogue- and controller-reading tests ran for real rather than skipping — including the three new tests and the whole pre-existing suite. All of this ran as nice -n 15 with GOFLAGS=-p=2 GOMAXPROCS=4 and CGO_ENABLED=0 (no -race, as asked, since g14 is overloaded). I ran merge-check.sh's own three steps by hand with the race detector intentionally left out (gofmt, go vet, go test -count=1 ./...), since this environment has gcc and the script would otherwise have picked -race: all three pass. The PR head's own statuses already say so: mesh/merge-gate reports "head 8108dd5c23c6 merged into trunk f0d39b4a4ab0 — pass: the change touches no module of the mesh's graph" and mesh/repo-check reports "head 8108dd5c23c6 merged into trunk f0d39b4a4ab0 — pass: its merge-check.sh passed".

mesh-admin merged commit 130c5d98a6 into main

2026-10-13 09:23:04 +00:00

mesh-admin deleted branch fix/616-the-base-builds-every-genesis-toolchain

2026-10-13 09:23:04 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-host#106