Judge a pull request into a release branch by that branch's controller and repositories (issue 704, ADR 0358) #329
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: novox/mesh-controller#329
Reference in New Issue
Block a user
What changed
This builds hq ADR 0358 (accepted, version 11) for hq issue 704, and fixes hq issue 709. Issue 709: mesh-lab's replays could run code a pull request wrote, while holding the container runtime's socket. This delivers together with mesh-catalog#297, which gives the build agent its judge cache. Both use the branch name
fix/704-release-branch-judge, which makes them one delivery group.releaseBranchOfasks the forge nothing for a base that is the repository's own trunk (the branch its module follows, or main when it records none) or mesh-controller's trunk. For any other base it asks the forge one question: does mesh-controller have a branch of that name? A 404 means no release branch. An answer that names no branch, names another branch, or cannot be read is an error.releaseJudgebuilds mesh-controller at the release branch. It uses mesh-host's validator from mesh-host's same-named branch, or the copy the judge vendors when there is none. A mesh-host pull request is judged with its own validator. A controller pull request judges itself.release,judged-by,validatorandbeside-at. Both status summaries open with[release <branch>, judged by its controller <commit>].GIT_CONFIG_GLOBAL=/dev/null,GIT_CONFIG_NOSYSTEM=1,GOENV=off,-buildvcs=false, andGOWORK=offfor the replays.MESH_JUDGE_CACHE): the copy and the homes are under its homes/, and the caches are its warm Go build cache and module cache. Only judge builds and the replays mount it. The replays may share it because their build is as trusted as a judge's: they run mesh-lab's trunk, which is reviewed code, against this check's judge, and nothing of the pull request except its catalogue, which they read as data.Trunk checks
The judge and the replays of a trunk check now run in the same isolated environment, which is stricter than before and closes issues 482 and 709 for them.
What a trunk check reads beside it, and what its verdict says, are unchanged.
Proof (tests written first)
internal/builder:-toolexechook and poisoned caches are neither run nor read during the replays;cmd/mesh-controller: release detection, trunks, the forge's answer read strictly, the beside refs, §7, and the verdict's fields.cmd/mesh-builder:release,elseandMESH_JUDGE_CACHEare passed through.Commands run:
gofmt -l,go vet ./..., andmerge-check.shagainst a throwaway PostgreSQL over TCP 127.0.0.1 (dynamic_shared_memory_type=mmap). It exited 0, with no FAIL and no NOT RUN.Rollout order
The delivery group is this pull request (mesh-controller, plus the build agent's mesh-builder image built from it) and mesh-catalog#297. The build agent's mesh-builder must carry this before the controller, or with it.
releaseandelse. mesh-lab is still asked at main. It builds the judge from mesh-controller at the release branch, by today's rule. A repository without the release branch fails its clone, so the check errors and never passes. The replays still run as on main today, open to issue 709, until the new mesh-builder lands.Not done here: the forge's comment line "read beside it:" prints commits only.
Reviewer's checklist
omitempty, and the readers are lenient.Delivery
novox/mesh-controller@847ffd6d1285— ready since 2026-10-14T14:40:17ZDelivery plan — builds build-agent, mesh-controller → ace, g14, novox, shanks; no bus step
Group
fix/704-release-branch-judge, in order:after: novox/mesh-catalogin novox/mesh-controller#329's description, orafter: novox/mesh-controllerin novox/mesh-catalog#297'sTransitions
The commit's note under
refs/notes/mesh-plankeeps every transition:git log --notes=mesh-plan.Merge check at
4a75cc51Judged: head
4a75cc51dda6merged into trunk535c7641ac41; read beside it: mesh-catalogb15846dd6e78, mesh-controller-main535c7641ac41, mesh-host1a2677882380, 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 novox as
build-1791982177864857946(builds --log build-1791982177864857946).Merge check at
ea7d91bfJudged: head
ea7d91bff190merged into trunk535c7641ac41; read beside it: mesh-catalogb15846dd6e78, mesh-controller-main535c7641ac41, mesh-host1a2677882380, 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 shanks as
build-1791982647000590148(builds --log build-1791982647000590148).Verdict: CHANGES at
ea7d91bff1Independent review of novox/mesh-controller#329 at
ea7d91bff1(4a75cc51plusea7d91bf), for issue 704 and ADR 0358. ADR 0358 is proposed, not accepted: it is at version 7, and its latest knowledge-base review (13:02 UTC) says "changes", on the same point as finding 1 below.What I ran in my own worktree:
gofmt -l cmd internal examplesprinted nothing.go vet ./...passed.merge-check.shexited 0 against a throwaway PostgreSQL (TCP 127.0.0.1, dynamic_shared_memory_type=mmap), with 26 packages ok. I stopped the server afterwards.What I checked and found correct:
builder.Checkon main535c7641and on this head, and compared the verdict and the log. They are identical apart from timestamps and the four new empty fields, which areomitemptyon the wire.besideOf(…, "")gives the same refs as before. A base ofmain, of the module's followed branch or of the controller's trunk asks the forge nothing.gitea_apireally does answer{"result":{"name":…}}, and a missing branch really does fail with…: 404 {…}; I checked both on the live forge. An unanswered forge errors the check.mesh-controllerbeside the check, at the release branch. It is built before any code of the change runs, and it is kept outside the mounted workspace. The cache key is the full commit of the controller, plus mesh-host's commit when mesh-host's validator is used. When the branch moves, the key changes, so a stale judge cannot be served. A controller pull request still judges itself.release/elseand checks as before. An old builder with a new controller checks outfeat/57-…in every repository beside the check. mesh-lab and mesh-tools have no such branch (404 on the live forge), so today that check errors.Findings:
replays/with/var/run/docker.sockmounted. The design behind it, check.go:64 and :998 ("mesh-lab's main, reviewed code — get the socket"), allows that only for mesh-lab's main. With this change, anyone who can create a branch with a release branch's name in mesh-lab gets root on the build node at the next release-branch check. Nothing checks that the branch is protected. Keep mesh-lab at main, as the ADR review asks, and add a test for it.result.nameis empty or missing returns false with no error, so the check runs as a trunk check. An empty name should be an error.base == "main"guard is untested. The guard is at checks.go:334. The test entries all recordRef: "main", so the followed-branch guard already covers that case, and removing themainguard passes every test. Add a case where a module recordsRef: "".GOCACHE=<workspace>/go-cache(check.go:1134). The change's own script writes to that same cache (check.go:612). This weakness existed before (issue 482, shared build caches), but the judge cache now keeps a judge built from a poisoned Go cache for every check of that head. Build the release judge with a Go cache outside the workspace.Verdict: CHANGES at
48b2906b5cThis is an independent review of novox/mesh-controller#329 at
48b2906b5c, for issue 704 and ADR 0358. ADR 0358 is still proposed, at version 9. The knowledge base's latest review, of version 8, says "changes", and version 9 has no review yet.What I ran in my own worktree
gofmt -l cmd internal examplesprinted nothing.go vet ./...passed.merge-check.shexited 0 against a throwaway PostgreSQL (TCP 127.0.0.1, dynamic_shared_memory_type=mmap). 26 packages were ok, with no FAIL and no NOT RUN. I stopped the server afterwards.What I checked and found correct
builder.Checkon main535c7641and on this head. The verdict and the log are identical apart from fresh commit ids, the time taken and four new empty fields. Those fields areomitemptyon the wire.Ref: mainwith noElsefor a release branch. The build seat (check.go:432) turns aRef: <release>, Else: mainrequest for mesh-lab into main. I reverted each of these on its own, and each time its test failed (TestBesideAReleaseBranch…,TestAReleaseBranchCheckReadsMeshLabAtItsTrunkEvenWhenItHasThatBranch).branchAnsweredtreats an empty name, another name, an unreadable answer and a non-404 error as errors. With the lenient line restored, the test fails.trunkOfis tested withmasterand with a controller that followstrunk. Restoring thebase == "main"guard makes the test fail.feat/57-config-and-provisioningtoday: I got a 404 from the live forge. The delivery plan moves the controller in tier 0 and build-agent in tier 1, so the "or in the same walk" window exists, and the body describes what happens during it.<workspace>-judges, which no container mounts.Findings
HOME=<workspace>and the workspace mounted read-write. The workspace's HOME is never cleaned:forgetLeftCredentialsremoves onlygit-credentialsand.npmrc.go buildstamps the version from git (-buildvcsis not off), and git reads$HOME/.gitconfig. One pull request'smerge-check.shcan therefore write<workspace>/.gitconfigwithcore.fsmonitor = <script>. At the next release-branch check, that script runs inside the judge's build, before compilation, and can rewrite the release controller's sources undercheck/mesh-controller. The poisoned judge is then kept in the judge cache under the honest commit key, and it judges every check of that head. I reproduced this locally: withHOMEholding such a.gitconfig,GOENV=offand a freshGOCACHE,go buildproduced a binary from sources the hook rewrote, while HEAD, and so the cache key, stayed at its commit.GOENV=offcloses only Go's own environment file.XDG_CONFIG_HOMEthere too),GIT_CONFIG_GLOBAL=/dev/null,GIT_CONFIG_NOSYSTEM=1, and-buildvcs=falseas the toolchain already uses (toolchain.go:176)..gitconfigin the workspace's HOME, and prove the kept judge does not change.judge-with-this-validator). It still usesGOCACHE=<workspace>/go-cacheand the workspace HOME. That judge is not kept across checks, but it is the release judge of that check, and the review asked for a cache no pull request's script can write. Use the same fresh cache and environment as in finding 1.Else, not on the release branch. At check.go:432, a request ofRef: <release>with noElsefor mesh-lab is still cloned at the release branch. The current controller never sends that request, so this is defence in depth. Still, the PR body says the seat "refuses a release ref for mesh-lab", and the code does not. Key the guard onspec.Release != "" && b.Ref == spec.Release, or refuse any ref but main, and test that case.trunkOf's "main when it records none" fallback is untested. It is at cmd/mesh-controller/checks.go:372. ReplacingtrunkOfwithfollowedBranchpasses every test. This is the earlier review's point 3 (a module that recordsRef: ""). A repository with no module is never compared with its forge default branch, only asked about once (a 404 means no release branch). That is acceptable, but say so in the comment.Merge check at
48b2906bJudged: head
48b2906b5ce4merged into trunk535c7641ac41; read beside it: mesh-catalog50861c74f8b4, mesh-controller-main535c7641ac41, mesh-host1a2677882380, 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 novox as
build-1791983635010871240(builds --log build-1791983635010871240).Out of date when it landed: out of date: judged against trunk
535c7641ac, the trunk is now c975dbf7b053; judged again on a recheck or when it is mergedMerge check at
b7084a19Judged: head
b7084a19e9bfmerged into trunkc975dbf7b053; read beside it: mesh-catalog02427a60ef78, mesh-controller-mainc975dbf7b053, mesh-host1a2677882380, 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 novox as
build-1791984660282163421(builds --log build-1791984660282163421).Out of date when it landed: out of date: judged against trunk
c975dbf7b0, the trunk is now 76304d9db817; judged again on a recheck or when it is mergedVerdict: CHANGES at
b7084a19e9This is an independent review of novox/mesh-controller#329 at
b7084a19e9, for issue 704 and ADR 0358. I reviewed it as core security code that runs on the live build nodes. ADR 0358 is accepted, at version 11. The knowledge base's latest review is of version 10 (13:23 UTC) and says "approve".What I ran in my own worktree
gofmt -l cmd internal examplesprinted nothing.go vet ./...passed.merge-check.shagainst a throwaway PostgreSQL (TCP 127.0.0.1, dynamic_shared_memory_type=mmap): exited 0, with 26 packages ok and no FAIL or NOT RUN. I stopped the server afterwards.What I checked and found correct
JudgeBuildEnv(check.go:1183): the running controller (judge), a controller pull request's own controller (self), the build with the change's validator, and the release judge. Each build sets its own HOME and XDG_CONFIG_HOME,GIT_CONFIG_GLOBAL=/dev/null,GIT_CONFIG_NOSYSTEM=1,GOENV=off,-buildvcs=false,GOPROXY=off, and a fresh GOCACHE and GOPATH outside the workspace..gitconfigand XDG fsmonitor hook and the Go env file, as the PR's tests do.<workspace>/go-cache. Then I rewrote the cached outputs, keeping their size, so that "the vendored validator" reads "the poisoned validator".48b2906b, all four tests fail: the PR's two and my two. The trunk judge then says "main's controller with the poisoned validator".mainonly (checks.go:312-321). The build seat forces main with a fallback and without one (check.go:432-443). When I reverted the seat's new condition,TestTheBuildSeatNeverReadsMeshLabAtAReleaseBranchfailed.TestATrunkIsMainWhenTheSourceRecordsNonefailed.go build.Findings
os.MkdirTemp("", "mesh-check-judge-")runs inside the build-agent container. That container mounts only mesh-state, the workspace (at the same path) and the docker socket (mesh-catalog modules/build-agent/module.json). Its/tmpis its own.--volume /tmp/mesh-check-judge-N:/tmp/mesh-check-judge-Nis therefore resolved on the host. dockerd creates that directory, and the toolchain container fills it with a full Go cache (235 MB for this repository, measured).defer os.RemoveAll(judgeHome)removes only the empty copy in the build-agent container. Every check leaves a few hundred MB in the host's /tmp, or in memory where /tmp is a tmpfs. ThewithinDirguard checks the wrong filesystem.<workspace>-judges(mesh-builder main.gojudgeCacheOf). It works, but it lives in the build-agent container's own layer, so it is lost at every redeploy.535c7641, every judge (self, validator, and the running controller) was built with the warm shared<workspace>/go-cache. Now each check compiles its judge cold.selfjudge can be altered by a hook that an earlier, different pull request planted.go buildwith CGO off and fixed GOFLAGS runs none of the change's code, so it is safe to share.Merge check at
2bee290eJudged: head
2bee290eea56merged into trunk76304d9db817; read beside it: mesh-catalogcb7bf94a77ea, mesh-controller-main76304d9db817, mesh-host1a2677882380, 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-1791986017411722467(builds --log build-1791986017411722467).Merge check at
2bee290eJudged: head
2bee290eea56merged into trunk76304d9db817; read beside it: mesh-catalogcb7bf94a77ea, mesh-controller-main76304d9db817, mesh-host1a2677882380, 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-1791986017411722467(builds --log build-1791986017411722467).Merge check at
2bee290eJudged: head
2bee290eea56merged into trunk76304d9db817; read beside it: mesh-catalogcb7bf94a77ea, mesh-controller-main76304d9db817, mesh-host1a2677882380, 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-1791986017411722467(builds --log build-1791986017411722467).Verdict: CHANGES at
2bee290eeaIndependent review of novox/mesh-controller#329 at
2bee290eea(issue 704, ADR 0358 v11), together with novox/mesh-catalog#297 at 47ef2644aca1, as core code for the live build nodes. I read review 12286.What I ran
gofmt -l cmd internal examples: nothing.go vet ./...: passed.merge-check.shwith a throwaway PostgreSQL (TCP 127.0.0.1, dynamic_shared_memory_type=mmap), stopped afterwards: exit 0, 26 packages ok, no FAIL, no NOT RUN.merge-check.shat #297's head with MESH_GATE built from this head (MESH_CHECK_MODULES=build-agent,gitea): exit 0.judges/: a poisoned Go cache entry and a.gitconfig/fsmonitor hook in the workspace reach neither a trunk judge nor the kept release judge, across two checks. Both pass.JudgeBuildEnvagainst one persistent Go cache took 14.9 s cold, then 0.88 s and 0.82 s warm (12 cores, toolchain on the host, no container start). The body's "about 1 s" holds.What I checked and found correct (review 12286's points)
docker runin the build seat: the check's own containers (in, check.go:577) mount only the workspace; the replays add only the runtime's socket (check.go:1055);dependencies.goandbuilder.gomount build trees and npm files. OnlyinJudgeBuild(check.go:611-619) mounts the judge cache'shomes/<id>andgo-cache/.judgeBuildDirs(check.go:1199) makes the home under the judge cache, which the agent sees at the host's own path, anddefer os.RemoveAll(judgeHome)removes it there. Nothing in the judge path usesos.MkdirTempany more. Without a judge cache, both go under the check's root, which is emptied before the clones (check.go:315) and removed afterwards.Findings
go testin a container that has/var/run/docker.sock, withHOME=<workspace>(the default inin), noGOENV=off, noGIT_CONFIG_GLOBAL, andGOCACHE=<workspace>/go-cache. A check's own script writes all of these.<workspace>/.config/go/envwithGOFLAGS=-toolexec=<hook>(the same fileaPlantedWorkspaceplants) and gave mesh-lab areplays/package. The hook ran in<workspace>/check/mesh-lab/replays, in the run that carries--volume /var/run/docker.sock. With the socket, that program candocker run -v <judge cache>:…, or the host's root.<workspace>/go-cachereaches the replays' test binary the same way.GOENV=off,GIT_CONFIG_GLOBAL=/dev/null,GIT_CONFIG_NOSYSTEM=1, and a Go cache that no check container mounts (the judge cache's, or one of its own). Then add the planted-env test for the replays.ADR 0358 §5: the claim holds. The gitea module's
weighTrunksweighs every open pull request's base, andmerge.ts:95compares against the pull request's own base. #297's new test passes with Node's runner (8 of 8 trunk tests).Merge check at
0214b454Judged: head
0214b45469ecmerged into trunk76304d9db817; read beside it: mesh-catalogcb7bf94a77ea, mesh-controller-main76304d9db817, mesh-host1a2677882380, 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 shanks as
build-1791987347185392290(builds --log build-1791987347185392290).Verdict: CHANGES at
0214b45469Independent review of novox/mesh-controller#329 at
0214b45469(issue 704, ADR 0358 v11, issue 709), together with novox/mesh-catalog#297 at 47ef2644aca1, reviewed as security-critical code for the live build nodes. I read review 12295.What I ran
gofmt -l cmd internal examples: nothing.go vet ./...: passed.merge-check.shwith a throwaway PostgreSQL (TCP 127.0.0.1, dynamic_shared_memory_type=mmap), stopped afterwards: exit 0, 26 packages ok, no FAIL, no NOT RUN.2bee290and the new test kept,TestTheReplaysRunWhereNoPullRequestReachesfails. At the head, it passes.<workspace>/go-cacheat both the old path and the copy's path, plus the planted-toolexecGo env file and.gitconfighook. With a judge cache, the replay ran honest and no hook ran. With check.go at2bee290, the replay ran the poisoned code.$MESH_CHECK_BESIDE/mesh-lab/replaysduring the gate. With a judge cache, the replays run from the copy and the rewrite never runs. Without one, see finding 1.Issue 709 with a judge cache: fixed. The copy is made right after mesh-lab's clone, before any container runs (check.go:457). The copy uses
git clone --no-local, and the host's git runs it, not a check container. The replays get a fresh HOME and XDG_CONFIG_HOME,GOENV=off,GIT_CONFIG_GLOBAL=/dev/null,GIT_CONFIG_NOSYSTEM=1,-buildvcs=false, and the judge cache's Go build and module caches (check.go:637-647, 1305).The author's reasoning for sharing the judge cache holds. The replays compile only mesh-lab's trunk and public modules that the checksum database verifies. Whatever holds the socket is already root-equivalent, so sharing the judge's Go cache gives the replays no reach they did not already have. The pull request's only input to the replays is the catalogue, which they read as data (see below).
Where pull-request-written data goes, for each run in internal/builder
in(check.go:598), used by the check's containers, the gate's module check and merge gate, and the repository's own check: the workspace is mounted read-write, with HOME and GOCACHE in the workspace. PR data reaches it by design. It has no socket and no judge cache, and runs as the builder's user, not root.inJudgeBuild(check.go:624): it mounts the judge cache'shomes/<id>andgo-cache. It compiles fresh clones, and for a self-judge or a validator change it also compiles the pull request's Go code. That build usesCGO_ENABLED=0,GOPROXY=offand-mod=vendor, so the compile runs none of the pull request's code. It only writes cache entries under the build's own content-addressed keys (action IDs).inReplays(check.go:637): it has the socket and the replay base and caches, and the workspace throughin. PR data that reaches it:MESH_REPLAY_CATALOGUE. mesh-lab's bed, store and resolver replays read image names, env, args and health commands from that catalogue. They start those images as unprivileged containers whose binds are only scratch directories.git show/rev-parseon the catalogue checkout ran no repository-config hook in my probe (git 2.56). This was already so on main.dependencies.goandbuilder.go: build trees and npm files. They are not changed here.Findings
JudgeCache == "",replay.labis empty, so the replays runroot/mesh-lab/replaysfrom the workspace, with the socket. Their Go cache (root/judge-go-cache) is also in the workspace.evil_test.gointoroot/mesh-lab/replays, and it ran in the replays'go test, the run that mounts/var/run/docker.sock.GOWORK=off. That keeps ago.workfile in a directory above the judge cache from being read. It is not reachable today.Since
2bee290: only check.go and release_branch_test.go changed (179 lines added, 9 removed). The judge-build path is unchanged, so the earlier points of 12248, 12264 and 12286 still hold, and so does the warm trunk judge (about 1 s, measured in 12295). Review 12295's findings 2 (clause 7) and 3 (the cold timings in the body) are done.Merge check at
847ffd6dJudged: head
847ffd6d1285merged into trunk76304d9db817; read beside it: mesh-catalogcb7bf94a77ea, mesh-controller-main76304d9db817, mesh-host1a2677882380, 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 shanks as
build-1791988447107965492(builds --log build-1791988447107965492).Verdict: CHANGES at
847ffd6d12Independent review of novox/mesh-controller#329 at
847ffd6d12(issues 704 and 709, ADR 0358 v11), which delivers together with novox/mesh-catalog#297 at 47ef2644aca1. I read review 12303 first.What I ran
gofmt -l cmd internal examplesprinted nothing.go vet ./...passed.merge-check.shagainst a throwaway PostgreSQL (TCP 127.0.0.1, dynamic_shared_memory_type=mmap) and stopped the server afterwards. It exited 0, with 26 packages ok, no FAIL and no NOT RUN.0214b45and kept the new test.TestTheReplaysNeverReadWhatAPullRequestWroteWithOrWithoutAJudgeCache/judge_cache_falsefailed with "the test the pull request wrote into the replays ran with the socket". My own self-judge test from review 12303 also failed in the no-cache case. At the head, both pass.evil_test.gointo$MESH_CHECK_BESIDE/mesh-lab/replays, the planted-toolexecGo env file and git hook, and a real poisoned Go cache entry for the replay package, planted at the workspace's path and at the copy's path. All of them pass at the head, and the poisoned-cache and hook tests for the trunk judge and the kept release judge still pass. In no case did the pull request's test or the hook run, and the poisoned entry was never read.docker infofails here with "permission denied" on the socket, and I did not use sudo. So I could not run the real volume sequence (finding 2 says what the first live check must show).Requested checks
hasReplaysis read at that moment.GOWORK=offis set inReplayEnv, the comment at cmd/mesh-builder/main.go:316 is fixed, and the body is fixed.0214b45the diff touches only cmd/mesh-builder/main.go, check.go and release_branch_test.go (178 lines added, 38 removed).judgeBuildDirsandinJudgeBuildare unchanged.Findings
/mesh-replays/mesh-lab/replaysas their working directory. That path exists only inside the check's named volume.os.MkdirTemp(Getwd(), "store-measure-")and passes that directory to sibling containers asHostConfig.Binds./mesh-replays/mesh-lab/replays/store-measure-*on the build node's root filesystem. postgres then initialises its data there, and the check leaves the directories behind. The volume and the replays' ownRemoveAllnever see this path.mesh.build.--- the replays (mesh-lab replays/)followed by go test'sok, and it must not saymesh-lab could not be copied for its replays. A create or copy failure is loud (the check's verdict is error).failwith "a replay of a core incident fails with this change", which blames the change for a problem of the build node (check.go:1096).mesh-check-check-replays, and the pre-removal at check.go:1328 would hit a concurrent check's volume. Ids fromlink.NewBuildID(build-<nanoseconds>) are unique and safe, so this does not happen with the ids the controller makes today.View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.