BuildMaster Documentation

General Blocks

General Blocks also allow you to define properties that operations will use, and that will control how contained statements and blocks
actually run.

Visual Mode

Text Mode (OtterScript)

General Group Properties

Current Server
sets the server used for execution of operations

Deployable
determines whether the current release in context has that deployable included, and skips the block if it does not

Working directory
sets the current working directory that file-based Operations will use

Asynchronous
when specified (along with an optional token), the entire block will run asynchronously (see below).

Timeout
the number of seconds to wait for the contained items to run; if they don't run in this time, an error will be raised

Retry count
if any of the contained items raise an error, then the entire block (and all nested blocks) will be run as many times
specified; if a retry succeeds, then the execution status will not change

Exclusive
when specified (with an optional token), if there are any other blocks that are are marked exclusive, either in the
current execution (or in all executions, when Global is specified), the block will wait until the other blocks finish;
if you specify a token, then this will only apply to other blocks that share this token

Disabled
when set, none of the statements in the entire block will execute; this is actually implemented in OtterScript as a
simple If/Else block with a predicate that's never true (i.e. if (false) {...})

Asynchronous Blocks

An asynchronous block works just like a general block, except that execution will continue
with the statement/block immediately following the asynchronous block while the asynchronous block
runs in the background. In this way, multiple long-running blocks can execute in parallel.

An await asynchronous operation statement will suspend the current execution until all asynchronous blocks have
been completed. The execution engine adds an implicit await to the end of any plan
if there are background blocks running, but you can always await sooner if part of your plan
depends on the asynchronous blocks completing.

If an asynchronous block is given a token, then this token must be supplied to an await
statement to act as a filter; that is, only asynchronous blocks with that specific
token will be awaited.

When an await asynchronous operation statement is executed, the execution status is inherited from the
background block if it is in an error or warn state. An await statement can
be enclosed inside a Try/Catch block to handle any recoverable errors that happened
in the background.

foreach server in @ServersInGroup(database-nodes)
{
# these will take an eternity to run, so run in background
with async
{
PSExec >> some really long-running script >>;
}
}
# Hopefully database servers are caught up by now, but wait just in case
await;
log-debug all async blocks finished!;