A build configuration usually has build triggers configured which automatically start a new build each time the conditions are met, like scheduled time, or detection of VCS changes, etc.
Besides triggering a build automatically, TeamCity allows you to run a build manually whenever you need, and customize this build by adding properties, using specific changes, running the build on a specific agent, etc.
On this Page:
There are several ways of launching a custom build in TeamCity:
- Click the ellipsis on the Run button, and specify the options in the Run Custom Build dialog described below.
- To run a custom build with specific changes, open the build results page, go to the Changes tab, expand the required change, click the Run build with this change and proceed with the options in the Run Custom Build dialog.
- Use HTTP request to TeamCity to trigger a build.
- Promote a build - see the section below.
Select an agent you want to run the build on from the drop-down list. Note that for each agent in the list, TeamCity displays its current state and estimates when the agent will become idle if it is running a build at the moment. Besides the possibility to run a build on a particular agent from the list, you can also use one of the following options:
- fastest idle agent — default option; if selected, TeamCity will automatically choose an agent to run a build on based on calculated estimates.
- all enabled compatible agents — select to run a build simultaneously on all agents that are enabled and compatible with the build configuration. This option may be useful in the following cases:
- run a build for agent maintenance purposes (e.g. you can create a configuration to check whether agents function properly after an environment upgrade/update).
- run a build on different platforms (for example, you can set up a configuration, and specify for it a number of compatible build agents with different environments installed).
On the General options you can also specify whether
- this particular build will be run as a personal one
- this particular build will be put at the top of the build queue
- all files in the build checkout directory will be cleaned before this build
This tab is available only for builds that have dependencies on other builds.
You can enforce rebuilding of all dependencies and select a particular build whose artifacts will be taken. By default, the last 20 builds are displayed. To increase the number of builds displayed in the drop-down to 50, use the teamcity.runCustomBuild.buildsLimit=50 internal property.
This tab is available only if you have permissions to access VCS roots for the build configuration.
The tab allows you to specify a particular change to be included to the build. The build will use the change's revision to checkout the sources. That is, all the changes up to the selected one will be included into the build.
Note that TeamCity displays only the changes detected earlier for the current build configuration VCS roots. If the VCS root was detached from the build configuration after the change occurred, there is no ability to run the build on such a change. A limited number of changes is displayed. If there is an earlier change in TeamCity that you need to run a build on, you can locate the change in the Change Log and use the Run build with this change action.
- Latest changes at the moment the build is started: TeamCity will automatically include all changes available at the moment.
- <Last change to include>: When you select a change in the drop-down list, TeamCity runs the build with the selected change and all changes that were made before it. The builds run with the changes earlier than the latest available is marked as a History Build.
|If you have branches in your build configuration (or in snapshot dependencies of this build configuration), you can choose a branch to be used for the custom build in this dialog.|
These settings are available only if you have permissions to change system properties and environment variables for the build configuration.
This tab allows adding new parameters/properties/variables,and editing or deleting them, as well as redefining values of the predefined ones.
When adding/editing/deleting properties and variables, note the following:
- For a predefined property/variable, only the value is editable.
- Only newly added properties/variables can be deleted. You cannot delete predefined properties.
Add an optional comment to the build.
|A greater build number does not mean more recent changes and the last build in the builds history does not reflect the state of the latest project sources: builds in the builds history are sorted by their start time, not by changes they include.|
Build promotion refers to triggering a custom build with an overridden artifact or snapshot dependency, i.e. manual launching of a build with dependencies configured, but using a build different from the build specified in the dependency.
To promote a build, open the build results page of the dependency build and click Actions | Promote.
For example, your build configuration A is configured to take artifacts from the last successful build of configuration B, but you want to run a build of configuration A using artifacts of a different build of configuration B (not the last successful build), so you promote an earlier build of B.
Build promotion affects only a single run of the dependent build. Once you click Promote, a build of the dependent build configuration which uses the artifacts of the specified build is queued. Any further runs of the dependent build configuration will use artifacts as configured (last successful, last pinned etc.), unless you use another promotion.
More details are available in the related blog-post.