From af6a3978408a577e4cb0fac04cbafeec9e67389f Mon Sep 17 00:00:00 2001 From: jochen Date: Sun, 27 Sep 2026 21:08:57 +0200 Subject: [PATCH] Issue 131: the trigger cannot be one build per changed module MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Correcting my own framing. The modules are a graph, not a flat set: several build from one repository, and some are the base another compiles on. Firing a build per changed module starts work that cannot succeed yet and reports one cause as a failure per dependent. Observed catching the mesh up by hand today — a compiler base had to move first, and when it failed the right behaviour was for its fifteen dependents to wait, not to fail identically. So what reacts to the forge's event has to resolve what changed into an order and hold a dependent while its base is unbuilt. That is a bigger thing than "rebuild what the commit touched", and cheaper to know now. --- .../00-report.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/04-ISSUES/131-nothing-tells-the-mesh-a-source-moved/00-report.md b/04-ISSUES/131-nothing-tells-the-mesh-a-source-moved/00-report.md index abd4182..f29ae06 100644 --- a/04-ISSUES/131-nothing-tells-the-mesh-a-source-moved/00-report.md +++ b/04-ISSUES/131-nothing-tells-the-mesh-a-source-moved/00-report.md @@ -52,6 +52,24 @@ the forge's business to know. The forge's module already declares the event. The build machine declares that it consumes nothing. +## What the trigger cannot be + +**Not one build per changed module.** The modules form a graph: several are built from one +repository, and some are the base another is compiled on — a runtime image, a compiler base, a +repository whose context a second module builds from. Firing a build for each changed module +independently would start work that cannot succeed yet and produce a failure per dependent, for one +cause. + +Observed while catching the mesh up by hand on 2026-09-27: a compiler base had to move before +anything compiled against it could build, and when it failed, the right behaviour was for its +dependents to wait rather than each fail the same way. Fifteen modules shared the cause. A trigger +that reports it fifteen times has buried it. + +So whatever reacts to the forge's event resolves what changed into an order, builds the bases first, +and holds a dependent while its base is unbuilt or failed. That is a larger thing than "rebuild what +the commit touched", and knowing it now is cheaper than discovering it from fifteen identical +failures. + ## Open questions - Is "the source moved" still a thing a person can assert by hand once the event path exists, or does