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.
Six merges landed today and the build machine built nothing — no build was
requested, refused or failed, because none was asked for. Asked what was wrong,
the mesh said every module was current with its source. All six had moved.
The trigger is not broken; there is no trigger. One repository still carries a
forge webhook aimed at a port belonging to a different service, and the rest carry
none. The intended shape is decided and unbuilt: the forge emits that a pull
request merged, the build machine reacts. The forge's module already declares the
event; the build machine consumes nothing.
Recorded with the question that outlasts the fix — "current with its source"
compares what was built against what the mesh was last told, so it agrees with
itself and can only ever agree. Whether the trunk moved is a question the forge
answers, and an overview that cannot ask it should stop claiming to know.
jschoubben