Build triggering: already existing and more upcoming in TeamCity 3.1
A flexible system of different build triggers in TeamCity allows to start the builds when it’s really necessary rather then use your company’s hardware resources at their most – running multiple builds at the same time and making you wait for the feedback on changes’ integration results.
Let’s now take a look at how TeamCity can help to “tame” builds clutter.
The most common case of firing a new build – changes committed to the version control system – can be altered by specifying a “quiet period” – time to pass with no changes in the build configuration VCS roots before TC starts a new build. In addition, you can use wildcards and operators to exclude parts of the VCS roots and ignore commits of particular users.
It’s quite common for many companies to create new builds periodically. In this case TeamCity can still limit the builds number if there are no changes pending to be built.
In TeamCity 3.1 which we plan to release soon, we’ve implemented more flexible build triggering options using Cron Expressions for more precise schedule tuning:
You can also specify to start a new build when a successful build of a dependent build configuration appears or when the previous build has failed.
In-depth build triggering options are, as usual, explained in online reference.