Skip to end of metadata
Go to start of metadata
You are viewing documentation of TeamCity 7.x, which is not the most recently released version of TeamCity. Please refer to the listing to choose another version.

Table of Contents

When creating a build configuration it is important to configure the sequence of build steps to be executed. Each build step is represented by a build runner and provides integration with a specific build or test tool. You can add as many build steps to your build configuration as needed. For example, call a NAnt script before compiling VS solutions.

Build steps are invoked sequentially.

Build step is failed if build process returned non zero exit code and Fail build if build process exit code is not zero build failure condition is enabled (see General Settings), otherwise build step is successful. Note that status of build step and build can be different. Build step can be successful, but build can be failed, because of some other build failure condition, not based on exit code. From the other hand if build step failed build will be failed too.

Since TeamCity 7.1: You can specify step execution policy based on build step status via "Execute step" option:

  • Only if previous steps were successful: select if you want to execute this build step only if status of the previous step was successful
  • Even if some of previous steps failed: select to make TeamCity execute this step regardless of the status of previous steps.
  • Always, even if build stop command was issued: select to ensure this step is always executed, even if build was canceled by a user.

In TeamCity 7.0: if a build step fails the rest are not executed, i.e. behavior is the same as Only if previous steps were successful execution policy in TeamCity 7.1.

  • You can copy a build step from one build configuration to another from the original build configuration settings page.
  • You can reorder build steps as needed. Note, that if you have a build configuration inherited from a template, you cannot reorder inherited build steps. However, you can insert custom build steps (not inherited) at any place and in any order, even before or between inherited build steps. Inherited build steps can be reordered in the original template only.
  • You can disable a build step temporarily or permanently, even if it is inherited from a build configuration template.

For the details on configuring individual build steps, refer to:

See also:

Concepts: Build Runner