Follow-up builds #23

Merged
mi merged 8 commits from mi/follow-up-builds AGit into main 2026-09-05 20:02:32 +02:00
8 Commits
Author SHA1 Message Date
mhoennigandClaude Fable 5.1 79a26dbf10 docs(prs): PR#23 records where the implementation went beyond the spec (point 7)
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-04 18:22:06 +02:00
mhoennigandClaude Fable 5.1 fc8dbf1c91 docs: follow-up builds in the reference, the init template, and the invariants (PR#23, point 5)
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-04 18:20:51 +02:00
mhoennigandClaude Fable 5.1 776defd391 docs(prs): PR#23 names every test that verifies it (point 4)
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-04 18:19:39 +02:00
mhoennigandClaude Fable 5.1 bbb4969fb9 Run follow-up builds after a green predecessor (PR#23, point 3)
FollowUpTrigger listens to build status transitions and, on a SUCCESS,
enqueues every definition of that branch whose afterSuccessOf names the
finished build — at the finished build's commit, not the branch's
current head, so a deployment ships the commit that was tested. Every
green run triggers, a repeated one again. The trigger is armed by
Watcher.start() and disarmed by stop(), so a CLI build never enqueues
into a JVM about to exit; the CLI names the follow-ups the server
would run instead. The event now carries the repository the result
belongs to, which the listener has to act on.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-04 18:19:10 +02:00
mhoennigandClaude Fable 5.1 ab522bc68d Pin the trigger of a follow-up build to the host (PR#23, point 2)
A branch's committed config loses afterSuccessOf from every trigger, and
where the host defines the same build as a follow-up, the branch's whole
trigger block: a follow-up is the host's way to hand deployment targets
and credentials to a green commit, so a branch may say what its
deployment does, never that or where it happens — otherwise it could
widen the host's selector to include itself. Both cases are logged
naming the branch, which the watcher now passes along.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-04 18:15:41 +02:00
mhoennigandClaude Fable 5.1 06eafc8010 Add trigger.afterSuccessOf, the follow-up build's predecessor (PR#23, point 1)
A build definition may name the build it follows. The key lives in the
trigger block, so it is never inherited and refused when written flat;
a definition with only a predecessor counts as triggered. An unknown
predecessor refuses the start of the primary configuration — a
deployment that silently never runs is the failure the flat-key check
exists to prevent — while a branch layer that dropped the name only
loses its follow-up with a warning, and an instance fragment is not
checked alone since its predecessor may live in the project config.
A cycle is refused wherever it appears.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-04 18:12:47 +02:00
mhoennigandClaude Fable 5.1 e4b935c684 docs(prs): PR#23 got its number
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-04 18:02:58 +02:00
mhoennigandClaude Fable 5.1 0f57549b4f docs(prs): the follow-up-builds PR-doc
A build definition may declare afterSuccessOf, running whenever the named
build of the same branch turns green — the deployment path chosen over a
deployCommand or a separate deploy section.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-04 18:01:38 +02:00