Configuring Build Steps
When creating a build configuration, it is important to configure the sequence of build steps to be executed.
Build steps are configured in the Build Steps section of the Build Configuration Settings page. Here, you can:
add new steps manually;
autodetect steps by scanning the source VCS repository;
copy and delete steps;
temporarily enable/disable steps.
Each build step is represented by a build runner and provides integration with a specific build or test tool. For example, call a NAnt script before compiling VS solutions. You can add as many build steps to your build configuration as needed.
Build steps are invoked sequentially.
The decision whether to run the next build step may depend on the exit status of the previous build steps, the current build status, or execution conditions.
The build step is considered failed if (1) the build process returned a non-zero exit code and (2) the "Fail build if build process exit code is not zero" build failure condition is enabled (see Build Failure Conditions); otherwise, the build step is considered successful.
Note that the status of a build step and the build itself can be different. All build steps can be successful, but the build can fail because of another build failure condition — not based on the exit code (like failing a test). On the other hand, if a build step has failed, the build will fail too.
For the details on configuring individual build steps, refer to the respective pages inside this section.
Execution policy
You can specify the step execution policy via the Execute step option:
Only if build status is successful: before starting the step, the build agent requests the build status from the server, and skips the step if the status is failed. This considers the failure conditions processed by the server, like failure on test failures or on metric change. Note that this still can be not exact as some failure conditions are processed on the server asynchronously (TW-17015)
If all previous steps finished successfully: the build analyzes only the build step status on the build agent, and doesn't send a request to the server to check the build status and considers only important step failures.
Even if some of the previous steps failed: select to make TeamCity execute this step regardless of the status of previous steps and status of the build.
Always, even if build stop command was issued: select to ensure this step is always executed, even if the build was canceled by a user. For example, if you have two steps with this option configured, stopping the build during the first step execution will interrupt this step, while the second step will still run. Issuing the stop command for the second time will result in ignoring the execution policy: the build will be terminated.
Since TeamCity 2020.1, you can also add granular execution conditions for build steps.
Autodetecting build steps
TeamCity can scan the source VCS repository of a project and autodetect build steps in Node.js, Kotlin, Python, Ant, NAnt, Gradle, Maven, MSBuild, Visual Studio solution files, PowerShell, Xcode project files, Rake, and IntelliJ IDEA projects.
In Build Steps, click Auto-detect build steps, and then select the proposed steps you want to add to the current build configuration. You can change their settings afterwards.
When scanning the repository, TeamCity progressively searches for project files on the two highest levels of the source tree. When searching, it takes into consideration the extension of the files. For example:
PowerShell:
.ps1.NET:
project.json,.proj,.csproj,.vbproj,.sln
If the detected steps have already been added to this configuration manually, TeamCity will skip those.