Say which modules a walk left unchanged, so a merge that moved nothing is not read as stranded (hq issue 611) #295
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: novox/mesh-controller#295
Reference in New Issue
Block a user
What: a walk's record gains
delivery.unchanged, mapping each module whose recorded build source (ADR 0267) holds none of the changed files to why. These are modules built from the merged repository whose directory holds a changed file, and modules that package the repository. A module the walk builds anyway (another merge's, or a dependent) is left out, somoduleskeeps meaning what the walk builds. A walk with nothing to walk names them in its note too. The field was decided on issue 611 under the operator's standing rule on small design limits.Why: mesh-controller #293's delivery plan, made while another walk built build-agent and route-proxy (issue 606), read them whole and named them. The walk then found none of #293's files in their build sources, moved nothing, and named no module. mesh-delivery read that as "never built", stopped the delivery and asked the operator about a change already on every machine.
Tests:
TestAMergeSaysTheModulesWhoseBuildSourceItLeftUnchanged(#293's shape, plus touched, unrecorded and truncated cases),TestAWalkSaysUnchangedOnlyWhatItDoesNotBuild, and the store testTestAWalkThatMovedNothingSaysWhichModulesMatchedWhatRuns(added to testdata/store-tests). They fail on main: the functions and field do not exist there.sh merge-check.shpassed against a throwaway store.Fixes issue 611 (with mesh-catalog's mesh-delivery reading, which goes after this).
Delivery
novox/mesh-controller@05576db018a4— delivered since 2026-10-13T08:40:14ZDelivery plan — builds build-agent, mesh-controller → ace, g14, novox, shanks; no bus step
Group
fix/611-an-unchanged-build-is-delivered, in order: novox/hq@18a5b2ac1a → novox/mesh-controller@05576db018 → novox/mesh-catalog@2f5e97030aMachines
Transitions
The commit's note under
refs/notes/mesh-plankeeps every transition:git log --notes=mesh-plan.Merge check at
05576db0Judged: head
05576db018a4merged into trunka688dcff394b; read beside it: mesh-catalogbc3b59227f46, mesh-controller-maina688dcff394b, 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 novox as
build-1791872505776464613(builds --log build-1791872505776464613).Verdict: approve at
05576db018No blocking findings.
The modules map is still only what the walk builds. Unchanged is a separate field on PlanDelivery. planBatch fills it through unchangedLeft against plan.Modules after planOfMoves and withhold, so a module the walk builds (another merge's, a dependent, or a carried one) is never named in both. TestAWalkSaysUnchangedOnlyWhatItDoesNotBuild pins that. Nothing writes an unbuilt row into modules, so staleIn and the other readers of modules see what they saw on main, which keeps clear of issue 606.
A stored walk without the field is safe. Unchanged is omitempty, inventory decodes the delivery column with plain json.Unmarshal (no DisallowUnknownFields), and a nil map is read as no module unchanged. A rollback to main is safe too. Main's PlanDelivery has no Unchanged, its json.Unmarshal ignores the unknown key, and a walk re-saved by main drops it, so mesh-delivery reads that walk as it does today. A walk with nothing to walk is done at its cut, so nothing re-saves it in practice. Deploy order does not matter either way, because mesh-catalog #265 behaves as main when the field is absent.
Tests: TestAMergeSaysTheModulesWhoseBuildSourceItLeftUnchanged, TestAWalkSaysUnchangedOnlyWhatItDoesNotBuild and the store test TestAWalkThatMovedNothingSaysWhichModulesMatchedWhatRuns pass at the head under -race. On main they fail to build: undefined unchangedLeft, and "PlanDelivery has no field or method Unchanged". That is the expected failure for a new field. At the head, go vet on ./cmd/mesh-controller and ./internal/inventory is clean. sh merge-check.sh exits 0 against a throwaway store (MESH_TEST_POSTGRES set), with every package passing under the race detector and every listed store test, the new one included, saying PASS.
Non-blocking: unchangedOfMerge's second loop names every module that packages the merged repository and recorded an untouched build source, whether or not any delivery plan named it. On every controller merge that leaves them alone, build-agent and route-proxy are listed, and so is the root-built controller through the first loop. mesh-delivery reads the field only for its plan's moved modules, so this is harmless, but it makes walk records and the nothing-to-walk note longer than they need to be.
Non-blocking: a module withheld under ADR 0299 is removed from plan.Modules before unchangedLeft runs, so a merge of this batch that leaves it unchanged lists it in Unchanged as well as in Withheld. For this walk's own merges the why is true. Its wording, "the build the mesh holds is its build", says nothing of the stopped merge's change that the module is withheld for. Consider leaving withheld modules out of Unchanged.
Non-blocking: for a module built from the repository's root, the why says "in its directory", which for that module is the whole repository.
Statuses at the head: mesh/merge-gate success ("head
05576db018merged into trunka688dcff39— pass: builds build-agent, mesh-controller → ace, g14, novox, shanks; no bus step; every …"), mesh/repo-check success ("pass: its merge-check.sh passed"), mesh/delivery success ("ready: it delivers once merged"), and mesh/delivery-group pending ("group fix/611-an-unchanged-build-is-delivered checking: 0 of 3 member(s) ready"). Merge the group only once its composed check passes for every head.