Although different actions will perform entirely different tasks, all Actions
have several things in common.
- Server Selection - Many actions are designed to be
executed on a server other than BuildMaster and, as such, require that a
server be selected. When an external server is used, the action's
configuration (file paths, etc) generally pertain to the remote server, as
opposed to the server BuildMaster is installed on.
- Enabled - Actions can be individually disabled for a particular
- Resume Next - When checked, the plan will continue to be
executed, regardless of the action's success. When an Action marked Resume
Next fails; however, the execution will be considered failed.
- Timeout - By default, actions will run until complete;
setting a timeout will fail the action after so many seconds have passed.
- Retry Count - Certain actions may be expected to fail when they
are executed for the first time. Setting a retry count will allow the action to
repeat execution until it succeeds, up to the specified retry count value.
- Log Errors as Warnings - If checked, any errors that occur during the action
execution will be logged as warnings instead and will not fail the execution.
To simplify the process of working with files and directories, many actions
utilize the "default directory." This can be thought of as the working directory
for both input and output files.
When an action utilizes both an input and output of files (compiling, for
example) and "default" is used for both of those actions, the input set of files
is replaced by the output set of files once the action is no longer
<< empty >>
After GetLatest (output only) runs
After Compile (input+output) runs
After Create File (output only) runs
After Create Zip File (input+output) runs
Note that each deployable will have its own default directory. That is, files
added to the default directory for an action running for the Web Deployable will
not be accessible by an action running for the Middle Tier Deployable.
Overriding the Default
From time to time, the default directory will need to be overridden. One of
the most common scenarios for this is transferring files from the Default
Directory to the action destination directory (such as d:\websites\example.com).
But there are other instances in which overriding makes sense, such as:
- Sharing a Directory between Deployables. Because default
directories are deployable-specific, if two or more deployables need to share
the same site of files, a directory other than the default must be used. This
could be an application-relative or absolute-pathed directory.
- Subfolders within a Deployable. Occasionally, an action may only
need to utilize a subfolder within the default directory. For example, signing
an executable file within the bin\debug path.
When a path is specified for either the source or target directory, the
following rules apply:
Deployable Relative. If no preceding slash is used in the path, then
the directory will be relative to the deployable's working directory. For
example, consider that the following files exist in the default directory:
images\ images\logo.png bin\ bin\debug\ bin\debug\app.dll ... file.cpp
Then, setting the directory to bin\debug would set the action's working
directory to be that path.
- Application Relative. When a tilde (~) precedes the directory path,
the resulting path will be placed outside of the deployable's directory and
into the directory used by the application. For example, the resulting path of
~\Src would be the same, regardless of which deployable within the application
- Absolute. Using any absolute path (e.g. D:\websites) will always
use that as the source or target directory.
While virtually any task could be accomplished with a custom shell script or "Execute Command Line" action,
there may be times when it is convenient to write a custom action using the BuildMaster SDK.
For a complete list of current actions available in the most recent version of BuildMaster,
visit the BuildMaster Actions page.
This content has the following tags: