When developers make changes, they generally build and test their code locally and commit their changes if the code ran successfully. Unfortunately, this process is not sufficient.
Code changes may break the production build because of environment differences, platform-specific issues, or incomplete commits. These issues leave the product in a broken state until the changes are backed-out of the product or the developer commits a fix, which often affects the entire development team. It is a time-consuming process to find the problem when multiple developers commit their changes simultaneously and the build breaks.
A Preflight Build is used to build and test a developer’s changes before those changes are committed. A "post-commit" source tree is simulated by creating a clean source snapshot and overlaying the developer’s changes on top of it. These sources are then passed through the production build procedure to validate the changes work successfully.
Developers are allowed to commit their changes only if the preflight build is successful. Because developer changes are built and tested in isolation, many common reasons for broken production builds are eliminated.
After a preflight build is configured, the general flow of interaction between the server, agent, and client is:
A developer invokes the client preflight program either through an IDE or via the command-line. The following arguments are specified in the XML configuration file or on the command-line:
Define which CloudBees CD server to use (hostname, ports, and so on),
Define the project, procedure, and parameters to use to start the preflight build, and
SCM-specific information to use (ports, changelists, and so on).
Next, the client preflight program connects to the CloudBees CD server and launches the specified procedure.
The job is started and the developer’s changes are uploaded.
If auto-commit was turned on, the client program waits for the job to complete. Otherwise, the client program exits immediately.
The job progresses until it gets to the special step added to the procedure to extract sources and overlay changes.
The agent-side driver creates a clean source snapshot based on configuration information passed to it from the client-side.
The step overlays changes [uploaded by the client] on top of the snapshot to simulate the developer’s check-in.
The build continues as usual, using the modified sources.
If the developer chose to auto-commit changes, the preflight program was waiting for the job to complete. If the job is successful, the changes are committed if:
No files were added or removed from the change sets.
No files were modified since the preflight build started.
All conditions set in the driver script were met.
Three components are required for a CloudBees CD preflight build:
Server —This is the main CloudBees CD server that will run the preflight builds.
Agent —This is any CloudBees CD agent machine that is setup as a resource for the server. This machine must be able to communicate with the source control system because it is responsible for creating a clean source snapshot on which the developer’s changes are overlayed.
Client —This is the machine where a developer has active code changes to submit for a preflight build. Like the agent, this machine must be able to communicate with the source control system because it is responsible for determining which files were modified so it can transmit these files to the agent.
Preflight is automatically installed with SCM plugins. CloudBees CD pre-installs numerous source code management (SCM) plugins including Accurev, Bazaar, CVS, ClearCase, Git, Mercurial, Perforce, SVN, StarTeam, Team Foundation Server, and Vault. Before you can use your preferred SCM, you will need it to communicate with the CloudBees CD server.
This section provides details for setting up and running Preflight builds in a typical build environment.
Adding the preflight snapshot step
A typical production build procedure has a step that extracts a clean source code snapshot before the actual build starts. For preflight builds, a special step needs to run in place of this snapshot step. This special step is responsible for creating the base snapshot and then overlaying the developer’s changes.
On the Procedure Details page, to create a new step click the Plugin link.
On the Choose Step panel, select Source Code Management.
Choose the ECSCM plugin for your SCM or from the right-pane, select the "Preflight" step for your SCM.
On the New Step page, notice that your SCM is displayed in the Subprocedure section.
Set the Resource name for the step to an agent that can communicate with the SCM system, so it can create the source snapshot.
The Parameter section also displays appropriate fields to enter information for your SCM. The following two fields are common to most SCMs:
Configuration–Enter the name you created for your SCM configuration.
Destination Directory–This is a path relative to the job’s workspace, where the source tree will be created.
Enter all other information required for your new step.
Choosing between snapshot steps
Only one snapshot step should run depending on whether a production or preflight build is invoked. To enable the appropriate step, add a checkbox-style parameter to the build procedure to determine whether or not the build is a preflight. Now, use that parameter in the Run Condition field on the two snapshot steps. In the following example, the parameter is named "preflight", with an unchecked value of "false" and a checked value of "true".
For the preflight snapshot step, set the run condition to
For the production snapshot step, set the run condition to
Choosing how files are uploaded
By default, when developers run preflight builds, their changes are uploaded to the job workspace via the server. However, if the job workspace is on a network share, accessible to the developer’s machine, a useful optimization is for files to be copied directly into the job workspace. To use the network share approach, set a flag on the top-level procedure that is invoked when running a preflight build. This property can be created on the Procedure Details web page as follows:
Create a nested property sheet on the procedure called
Create a property in that procedure called
waitForStepwith a value of "1". This property can be created from the command-line by calling:
ectool setProperty ec_preflight/waitForStep 1 --projectName <project> --procedureName <procedure>
The agent machine must be able to communicate with the SCM system to create the source snapshot.
From a developer’s machine, there are two ways to start preflight builds:
From an IDE:
Eclipse Open a Run dialogue, select Launch Commander Procedure, then select an existing preflight configuration or create a new one. For more information, see the CloudBees CD Automation Platform Eclipse Integration Tech Note PDF file or the Eclipse plugin.
Visual Studio (See the CloudBees CD Automation Platform Visual Studio Tech Note PDF file or the Visual Studio plugin)
From the command line:
The executable program,
ecclientpreflight, is used to run a preflight build from the command-line. This program is included in the CloudBees CD "Tools" installation. When you run ecclientpreflight, configuration options can be passed in an XML configuration file or on the command-line.
If the same option is specified in both the configuration file and on the command-line, the value passed on the command-line takes precedence. The XML configuration file can be passed to the program via the
--configoption. If the XML configuration file is not passed in, current and ancestor directories are searched for a file named "
.preflight", using the first one it finds as the configuration file.
Generally, a "
.preflight" file is stored at the root of a developer’s workspace, containing configuration information specific to that workspace.
In the following samples, the SCM was set to Perforce. Some options may be specified using an abbreviated format (
-c, with a single dash) or a more verbose format (
--config, with two dashes).
Load configuration options from the specified XML file. If
Display debugging information.
Display version information.
Display this information.
Server Communication Options
The host name (defaults to localhost).
The HTTP port (defaults to 8000).
The HTTPS port (defaults to 8443).
If set, only secure connections are used. Off, by default.
The response timeout in seconds (defaults to 180).
The name of the CloudBees CD user to login as.
The password for the specified user. If blank and the user has no active session, a prompt to enter the password will be provided.
Property path to a property sheet containing the driver scripts that will be loaded and run after a connection to the server is established. Defaults to
The name of a property in the sheet specified by driverLocation. This is the main driver script that will be loaded and run after a connection to the server is established.
If specified, debug information is logged. Off, by default.
Where to store log and other files. Defaults to the user’s home directory.
Procedure Invocation Options
The name of the CloudBees CD project containing the procedure to invoke.
The name of the CloudBees CD procedure to invoke.
Enter additional parameters to the procedure. May appear multiple times. If any parameters were specified in the config file, those supplied on the command-line append to that list, overriding parameters with the same name.
The priority of the job. Possible values are low, normal, high, highest. If left unspecified, defaults to normal.
The number of seconds to wait for the job to complete when auto-committing changes. Defaults to 3600 seconds (1 hour).
Wait for the job to complete and report its outcome. This action does not occur by default unless a set of SCM charges are being committed automatically.
Run the procedure and exit immediately. The SCM driver is not downloaded in this case.
The name of the SCM, required, unless the procedure is invoked in 'run only' mode. The driver is downloaded from
Valid values: ECSCM-Accurev, ECSCM-Bazaar, ECSCM-ClearCase, ECSCM-CVS, ECSCM-Git, ECSCM-Mercurial, ECSCM-Perforce, ECSCM-Repo, ECSCM-StarTeam, ECSCM-SVN, ECSCM-TFS, ECSCM-Vault.
Whether or not the changes should be automatically committed if the job completes successfully. Off, by default.
A comment for the auto-commit.
The value of P4PORT. May also be set in the environment. This is a required value.
The value of P4USER. May also be set in the environment. This is a required value.
The value of P4PASSWD. May also be set in the environment.
The value of P4CLIENT. May also be set in the environment. This is a required value.
The name of a Perforce client used to create a base snapshot before overlaying local changes. Defaults to the value of
The changelist number (or default) whose changes are being tested. May be specified multiple times. If no changelists are specified, all client changelists will be used.
The following is a sample XML configuration file with all options specified:
myUser myPass CloudBees CDServer 1234 2345 3456 0 3456 /server/ec_preflight/alternateDrivers myMainClientDriver myProject myProcedure branch main preflight true high 1 3600 perforce perf:1234 myUser myPass myUser-main-clientmyUser-main-template default 67382 1 Fixing bug 38582.
In most cases, a developer does not need to override all default values and will probably want to specify passwords and some SCM-specific options on the command-line. The following is a more typical XML configuration:
myUser commanderServer myProject myProcedure branch main preflight true 3600 perforce perf:1234 myUser myUser-main-client
If this file is stored in a
.preflight file at the top-level of a source tree, the command to start the preflight would look something like this:
ecclientpreflight --p4changelist 56793 --autoCommit 1 --commitComment "Fixing bug 38582."
CloudBees CD includes preflight support for some of the most common Source Control (SCM) systems. For an SCM plugin you installed, look for a Help link for that plugin (on the Plugins page). Command-line options are included in this Help topic for the following SCMs:
The command-line options for the Perforce driver for
|Perforce Options / Descriptions|
The value of P4PORT may be set in the environment also.
The value of P4USER may be set in the environment also.
(Optional) The value of P4PASSWD may be set in the environment also.
The value of P4CLIENT may be set in the environment also.
(Optional) The name of a Perforce client used to create a base snapshot before overlaying local changes. Defaults to the value of ` --p4client` if not specified.
(Optional) The changelist number (or default) whose changes are being tested and can be specified multiple times. If no changelists are specified, all client changelists will be used.
(Optional) The changelist number the Preflight Job should use when sync’ing the source tree. Values are: head —The most recent changelist anywhere in the P4 depot (default). have —The changelist for the most recent file that was synced to 'p4client' changelist. This is a p4changelist number.
The command-line options for the Subversion driver for
|Subversion Options / Descriptions|
The path to the locally accessible source directory in which changes were made.
Use this option to update the agent workspace created during preflight — updated to HEAD. By default, the agent workspace is updated to the revision found in the client workspace.
Causes the preflight process to ignore svn externals.
The command-line options for the AccuRev driver for
|AccuRev Options / Descriptions|
(Optional) The value of ACCUREVUSER may be set in the environment also. If not specified, the default is to the CloudBees CD user.
The value of ACCUREVPASSWD may be set in the environment also. This is a required value.
(Optional) Use this option to scan the client workspace for all pending elements using the "stat -fn -p" command. By default, the workspace is scanned for all kept elements using the "stat -fn -k" command.
The value of the ACCUREVPATH. Also may be set in the environment.
Preflight support for ClearCase is available only for snapshot views. The command-line options for the ClearCase driver for `ecclientpreflight ` are:
|ClearCase Options / Descriptions|
The path to the locally accessible source directory where changes were made.
The path to the appropriate config spec on a UNIX platform for the current view.
The path to the appropriate config spec on a Windows platform for the current view.
The relative path for the current view [on a UNIX platform] from the view root to the directory where changes were made.
The relative path for the current view [on a Windows platform] from the view root to the directory where changes were made.
The command-line options for the Bazaar driver for
|Bazaar Options / Descriptions|
The developer’s source directory.
Branch name for the preflight.
The command-line options for the Git driver for
|Git Options / Descriptions|
The Git directory to process.
The command-line options for the CVS driver for
|CVS Options / Descriptions|
The path to the repository.
The module name for the preflight.
The developer’s source directory.
The command-line options for the Mercurial driver for
|Mercurial Options / Descriptions|
The path to the locally accessible source directory in which changes were made. Generally, this path is to the root of the workspace.
The command-line options for the Repo driver for
|Repo Options / Descriptions|
The developer’s source directory.
The path to the source directory, used by the agent.
The command-line options for the StarTeam driver for
|StarTeam Options / Descriptions|
The StarTeam project name.
The command-line options for the Team Foundation Server driver for `ecclientpreflight ` are:
|TFS Options / Descriptions|
The equivalent value to Collection in VS2008 and under. If you use this option, it is assumed you are using TF version VS2008 or under and it will use the option /server in the preflight. This field is required if you have VS2008.
The URL that points to /collection. This value is used for VS2010. If you specify this value, the command uses the option /collection when it executes the TF query for preflight. This field is required if you have VS2010.
The path to the locally accessible source directory in which changes were made. Generally, this is the path to the root of the workspace.
The workspace containing the data for the preflight.
--debug option to `ecclientpreflight ` provides additional information about internal actions taken when starting the preflight build. By modifying the properties containing driver scripts, debug output can be added where needed.
If you want to capture debug information to a log file, use the ` --log` option. By default, logs are stored in the user’s home directory. To change this location, use the ` --logDir` option.