VCS triggers automatically start a new build each time TeamCity detects new changes in the configured VCS roots.
TeamCity periodically (according to root's Changes Checking Interval of a VCS root) polls VCS roots of the build configuration for changes. Newly detected changes appear as Pending Changes of a build configuration.
A new VCS trigger with default settings triggers a build each time new changes are detected.
By default, If you have a build chain (i.e. a number of build configurations interconnected by snapshot dependencies), automatic triggering of builds is performed in one direction only: if the first build in chain is triggered, all the builds it depends on are triggered too, but not vice versa. (Learn more about snapshot dependencies) Use this option to change this behaviour.
If you have fast builds and enough build agents, you can make TeamCity launch a new build for each check-in ensuring that no other changes get into the same build. To do that, select the Trigger a build on each check-in option. Moreover, if you select the Include several check-ins in build if they are from the same committer option, and TeamCity will detect a number of pending changes, it will group them by user and start builds having single user changes only.
This helps in sorting out whose change has broken a build, or caused new test failure.
By specifying the quiet period you can ensure the build is not triggered in the middle of non-atomic check-ins consisting of several VCS check-ins.
Quiet period is a period (in seconds) that TeamCity maintains between the moment the last VCS change is detected and a build is added into the queue. If new VCS change is detected in the Build Configuration within the period, the period starts over from the new change detection time. The build is added into the queue only if there were no new VCS changes detected within the quiet period.
Note that actual quiet period will not be less than maximum checking for changes interval among build configuration VCS roots. Because TeamCity must ensure that changes were collected at least once during the quiet period.
Quiet period can be set to the default value (which can be changed globally at the Administration | Global Settings page), or custom value can be specified.
If no trigger rules specified, a build is triggered upon any detected change displayed for the build configuration. You can affect the changes detected by changing VCS root settings and specifying Checkout Rules.
To limit the changes that trigger the build, use VCS trigger rules. You can add these rules manually in the text area (one per line), or use the Add new rule option to generate them.
Each rule is ether an "include" (starts with "+") or an "exclude" (starts with "-").
The general syntax for a single rule is:
For each file in a change the most specific rule is found (the rule matching the longest file path). The build is triggered if there is at least one file with a matching "include" rule or a file with no matching rules.
Skip to end of metadata Go to start of metadata