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.
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>
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>
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>
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>
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>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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