• Support
• Documentation
• BuildMaster
• Deployment Automation
• Deployment Plans
• Actions

Actions

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.
• 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.

Default Directory

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 executing.

For example:

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.

Override Rules

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 used that.
• Absolute. Using any absolute path (e.g. D:\websites) will always use that as the source or target directory.