bldr wait-for
Block until a resource reaches a state, then say what happened and how long it took
bldr wait-for
Block until a resource reaches a state, then say what happened and how long it took.
Exits 0 when the condition is met, 1 when the resource settled on something else, 2 on timeout, 3 when there is no such resource — so a script can tell "it finished badly" from "it has not finished" without reading the message.
bldr [BLDR FLAGS] wait-for [WAIT-FOR FLAGS] <COMMAND>-t, --timeout <DURATION>
Give up after this long — 90s, 5m, 2h, or a bare number of seconds. Exits 2 if it elapses first
Defaults to 10m.
bldr wait-for build
Wait for a build to finish.
By default any terminal state counts — succeeded, failed or cancelled — because "wait until it stops" is the more primitive thing to ask for. The exit code then reports whether the wait succeeded, not whether the build did: a build that fails still exits 0. Use --state SUCCEEDED when the build's verdict is what you are gating on.
bldr [BLDR FLAGS] wait-for [WAIT-FOR FLAGS] build [BUILD FLAGS] <BUILD-ID><BUILD-ID>
Required.
--state <STATE>
Require exactly this state: succeeded, failed, or cancelled. Reaching a different terminal state exits 1
bldr wait-for cluster
Wait for the cluster to reach a size.
Counts connected peers, which is what the node can report as a live stream. That is not the same as etcd cluster membership: a member that has joined but is unreachable is in the membership and not in this count. There is no membership stream to subscribe to today, and polling cluster info would be exactly the thing this command exists to avoid.
bldr [BLDR FLAGS] wait-for [WAIT-FOR FLAGS] cluster [CLUSTER FLAGS]--peers <N>
Wait until at least this many peers are connected
Required.
bldr wait-for deployment
Wait for a deployment to finish. Same default as build
bldr [BLDR FLAGS] wait-for [WAIT-FOR FLAGS] deployment [DEPLOYMENT FLAGS] <DEPLOYMENT-ID><DEPLOYMENT-ID>
Required.
--state <STATE>
Require exactly this state: succeeded, failed, or cancelled
bldr wait-for node
Wait for the node to answer.
The one wait that cannot be event-driven: a daemon that has not started has no stream to subscribe to. Runs before the client connects, so it is usable on a node that is not up yet — which is the whole point.
bldr [BLDR FLAGS] wait-for [WAIT-FOR FLAGS] nodebldr wait-for run
Wait for a run to settle.
"Settled" means it has stopped changing on its own — running, failed or stopped — rather than "finished", because a healthy run's steady state is running and waiting for it to end would hang. Use --state running to require that it came up.
bldr [BLDR FLAGS] wait-for [WAIT-FOR FLAGS] run [RUN FLAGS] <RUN-ID><RUN-ID>
Required.
--state <STATE>
Require exactly this state: running, failed, or stopped