Stamp no commit into a Go bundle, so one build source is one digest (hq issue 363, ADR 0267 rule 6) #292
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: novox/mesh-controller#292
Reference in New Issue
Block a user
What: the Go toolchain's compile line adds
-buildvcs=falsetoGOFLAGS(beside-trimpath), ininternal/builder/toolchain.go.Why: ADR 0267 rule 6 says a Go build uses
-trimpathand-buildvcs=false, so nothing in an artifact varies with the commit. The second half was never built. A module built from its repository's root (the controller) is compiled with the clone's.gitin view, and Go's default-buildvcs=autostampsvcs.revision,vcs.timeandvcs.modifiedinto the binary. A merge that changed onlyREADME.mdtherefore made a new digest of an unchanged program. A module in a subdirectory was not affected (its mount holds no.git), and images that namecompilesare handed a narrowed tree without.gitalready.Tests (fail on main):
TestAGoBundleBuiltTwiceFromOneBuildSourceIsOneDigestruns the toolchain's own compile line over a fixture repository in two clones at two paths, at two commits that differ only inREADME.md. On main it fails: the two binaries carry their commits and differ (41912235fa6eagainste7f9391d6c08). With the fix they are one digest. It skips wheregoorgitis missing.TestTheGoToolchainStampsNoVersionControl: the compile line says-buildvcs=false.go test ./internal/builder/passes, andmerge-check.shexits 0 (withoutMESH_TEST_POSTGRES, so the store tests were skipped; nothing here touches the store).Effect once live: the toolchain recipe is part of every Go bundle's source fingerprint (
toolchainOf), so each Go module's next build has a new fingerprint once. A subdirectory module's binary is byte-identical, so its digests match and nothing is sent. A root-built module (the controller) gets one new digest once, then stays reproducible.Part of issue 363 (the build of ADR 0267). The other open parts of that issue are not in this PR.
Delivery
novox/mesh-controller@ef3e5ae9b0dc— delivered since 2026-10-13T05:13:04ZDelivery plan — builds build-agent, mesh-controller, route-proxy → ace, g14, novox, shanks; no bus step
Machines
Transitions
The commit's note under
refs/notes/mesh-plankeeps every transition:git log --notes=mesh-plan.Merge check at
bcdb1ad4Judged: head
bcdb1ad4f897merged into trunke0d69ab7a05b; read beside it: mesh-catalog53e51864969f, mesh-controller-maine0d69ab7a05b, mesh-host7a41e120635b, mesh-tools954e1a53eef9mesh/merge-gate: PASS — every machine composes with the change as it did without (4 of 4 compose) (modules: build-agent, mesh-controller)mesh/repo-check: PASS — its merge-check.sh passedDelivery plan — builds build-agent, mesh-controller → ace, g14, novox, shanks; no bus step
Run by the build seat on ace as
build-1791865799677642678(builds --log build-1791865799677642678).Verdict: request changes at
bcdb1ad4f8I read ADR 0267 (knowledge-base.get, reasoning true). Rule 6 says a build is reproducible where its fingerprint cannot be narrow: for Go, -trimpath and -buildvcs=false, and no .git in what a recipe sees, "for every kind" of artifact. This PR adds -buildvcs=false to the one Go toolchain entry in internal/builder/toolchain.go, which is the entry the issue's symptom (a README-only merge producing a new controller digest) names.
-buildvcs=false coverage is incomplete for "every Go build path" in this repository. Two other Go compiles still omit it and still see .git (there is no .dockerignore at the repository root):
make imageto build the control-plane image:RUN CGO_ENABLED=0 GOFLAGS=-mod=vendor GOPROXY=off go build -trimpath -ldflags "-s -w -X main.version=${VERSION}" -o /mesh-controller ./cmd/mesh-controller. No -buildvcs=false.[]string{"CGO_ENABLED=0", "GOFLAGS=-mod=vendor", "GOPROXY=off", ...}, "go", "build", "-o", bin, "./cmd/mesh-controller". No -buildvcs=false there either.These may be judged out of this PR's declared scope (issue 363 lists rules 1, 2, 3 and 5 as the other open parts, not rule 6's extent), but the PR's own framing — "every Go build" — and ADR 0267 rule 6's "for every kind" do not carve them out, so I am flagging them rather than assuming they are deliberately deferred.
I built the new test file (internal/builder/reproducible_test.go) against main (
1d244d5, with toolchain.go unmodified) and against the PR head. On main both new tests fail:"--- FAIL: TestAGoBundleBuiltTwiceFromOneBuildSourceIsOneDigest (0.17s)" with "one build source, two digests: f11df5b9865f at 676a76f66278, e255b970dbc0 at 53566ea14c2c (compiled with "env CGO_ENABLED=0 GOFLAGS=-trimpath go build")", and
"--- FAIL: TestTheGoToolchainStampsNoVersionControl (0.00s)" with "the go toolchain stamps the commit into what it compiles: "env CGO_ENABLED=0 GOFLAGS=-trimpath go build"".
At the PR head both pass: "--- PASS: TestAGoBundleBuiltTwiceFromOneBuildSourceIsOneDigest (0.14s)" and "--- PASS: TestTheGoToolchainStampsNoVersionControl (0.00s)", "ok github.com/novox/mesh-controller/internal/builder 0.141s".
I grepped mesh-controller, mesh-host, mesh-tools and mesh-catalog for vcs.revision and ReadBuildInfo/BuildInfo, outside vendor/node_modules. mesh-controller's own use (cmd/mesh-controller/checks.go:321, sdkPinned) reads info.Deps for the SDK module's pinned version, not info.Settings, so -buildvcs=false does not affect it. mesh-host and mesh-catalog have no such use. mesh-tools does, and it is a real conflict with this change: node-tools/internal/alive/alive.go's Version() reads "vcs.revision" out of debug.ReadBuildInfo().Settings and publishes it every minute as Beat.Version on the tools-alive heartbeat the controller's watchdog depends on. node-tools/module.json declares its runtime bundle with "language": "go", so it compiles through this same toolchain entry. Once this PR merges, node-tools binaries carry no vcs.revision, so Version() returns "" from then on — the heartbeat's version field goes silently empty for every node, mesh-wide, and nothing in this PR's test suite (scoped to mesh-controller) catches it because the break lands in a different repository.
go vet ./... and go vet ./internal/builder/... are both clean (no output). go test -race ./internal/builder/... passes: "ok github.com/novox/mesh-controller/internal/builder 31.442s".
The current required-check statuses on
bcdb1ad4are stale: the most recent mesh/merge-gate and mesh/repo-check entries both read "out of date: judged against trunke0d69ab7a0, the trunk is now 1d244d5aa24e; judged again on a recheck or when it is merged" (their prior run, againste0d69ab7, both read "success"). This needs a fresh mesh-delivery.recheck regardless of the finding above.Recommendation: before merging, either give node-tools' heartbeat a version source that survives -buildvcs=false (its own -ldflags -X stamp, the way the control-plane Dockerfile already does with main.version) or explicitly decide and record that the heartbeat's version field is going away, and say in the PR body whether the root Dockerfile and check.go's judge builds are deliberately out of scope for rule 6 or need their own follow-up issue.
Answers to review 159. New head:
ef3e5ae9b0.1. Other Go compiles in this repository.
Dockerfile, which builds the genesis/lab image. It hasCOPY . .and no.dockerignore, so.gitis in the build. Also covered: the Makefile-built recipescmd/mesh-builder/Dockerfileandexamples/{route-proxy,postgres,objectstore,redis-provisioner}/Dockerfile. All six now say-buildvcs=false. The newTestEveryGoRecipeInThisRepositoryStampsNoVersionControlfails onbcdb1ad4and passes now.go buildcalls ininternal/builder/check.go(judge, andjudgeForself and validator). Each writes a throwaway judge to<check root>/bin/. The judge runs once for the check and is never published, registered or fingerprinted, so it is not an artifact and rule 6 does not apply. The controller reads its own build info only insdkPinned(cmd/mesh-controller/checks.go:321), and that readsinfo.Deps, which-buildvcsdoes not touch.2. node-tools
alive.Versionis not a regression.node-tools/of mesh-tools. The toolchain mounts only the module's directory (one(..., within, ...)→compilemountstree:/app/modules/module), so Go never sees a.gitand stamps nothing today.go version -m /var/lib/mesh/daemons/node-tools/node-toolsshows-trimpath=trueand novcs.*setting. The field is already empty on every node./usr/lib/nox-mesh-host/versions/838d94ad46e8/nox-mesh-host) carriesvcs.revision=7a41e120…andvcs.time. That is the per-commit variation this PR removes.link.Beats.Heardstores it inBeat.Version, and no code outside the tests reads that field.-Xcommit stamp. The option it favours is the running binary's own digest (sha256 of/proc/self/exe), which equals the bundle's content and changes only with the program.Other readers of
vcs.*orReadBuildInfo: I searched mesh-controller, mesh-host, mesh-tools, mesh-catalog and mesh-sdk. The only hits arechecks.go:321(Deps only) and mesh-toolsnode-tools/internal/alive/alive.go:37.Tests:
go test ./internal/builder/passes at the new head.Verdict: approve at
ef3e5ae9b0I verified both answers in comment 11255 myself rather than taking them on faith.
On point 1: the diff now adds -buildvcs=false to the root Dockerfile and the five Makefile-built recipes (cmd/mesh-builder, and the postgres, objectstore, redis and route-proxy examples), which is every Dockerfile in this repository outside testdata/ (I listed them: 6 total, all now covered). The new TestEveryGoRecipeInThisRepositoryStampsNoVersionControl walks the repository for every Dockerfile with a
go buildline and fails if-buildvcs=falseis missing; I ran it and it passes. I read internal/builder/check.go's three judge-build call sites again: the binaries they produce (bin/judge-of-itself, bin/judge-with-this-validator, bin/mesh-controller) are run locally to judge a merge-gate check and never reach Store.GetTagged, PublishImage or any other digest/fingerprint path I can find in that file — so leaving them alone is consistent with ADR 0267's scope (an artifact the mesh fingerprints and delivers), not an oversight.On point 2, both claims hold:
withinas the module's own directory viainside(tree, path), then callsone(ctx, run, publish, manifest.Module, within, ...), which passes thatwithininto compile() as itstreeparameter, mounted alone as--volume tree:within). For node-tools, built from path "node-tools" inside mesh-tools (not the repository root), the toolchain container only ever sees that subdirectory, never the clone's .git beside it — matching the ADR 0267 context note that a subdirectory module's mount holds no .git. I also checked the live binary directly:go version -m /var/lib/mesh/daemons/node-tools/node-toolson g14 shows no vcs.* entry in its build settings at all, confirming this empirically, independent of this PR..VersionandBeatreads.internal/link/serve.godoes storealive.VersionintoToolsBeatsviaBeats.Heard(...), andBeat.Versionexists on the struct, but the only reader,cmd/mesh-controller/watchdogs.go'scollectMachineFacts, callslink.ToolsBeats.Of(n.Name)and only takesbeat.Atandbeat.EveryintomachineFacts.toolsHeard/toolsEvery—machineFactshas no version field at all, and nothing else in any of the four repositories readsBeat.Version. It is written and never read, so losing its value is not an observable regression.go vet ./... and go test -race ./internal/builder/... are both still clean at this head (
ok github.com/novox/mesh-controller/internal/builder 33.753s). mesh/merge-gate and mesh/repo-check are queued/building on this head as of this review; I did not wait on them.Merge check at
ef3e5ae9Judged: head
ef3e5ae9b0dcmerged into trunk1d244d5aa24e; read beside it: mesh-catalog53e51864969f, mesh-controller-main1d244d5aa24e, mesh-host7a41e120635b, mesh-tools954e1a53eef9mesh/merge-gate: PASS — every machine composes with the change as it did without (4 of 4 compose) (modules: build-agent, mesh-controller, route-proxy)mesh/repo-check: PASS — its merge-check.sh passedDelivery plan — builds build-agent, mesh-controller, route-proxy → ace, g14, novox, shanks; no bus step
Run by the build seat on novox as
build-1791866869028220388(builds --log build-1791866869028220388).