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.
Subscribe to Blog updates
Thanks, we've got you!
How To Choose a CI/CD Tool: A Framework
In this blog post, we offer general guidelines for selecting an appropriate CI/CD solution and delve into how TeamCity fits into this framework.
Increase Your Productivity With TeamCity Documentation Examples for the Kotlin DSL
Take advantage of extensive Kotlin DSL documentation for TeamCity - now with examples! Read more about how it might increase your productivity in this blog post.
Monitor Your TeamCity Builds with Datadog CI Visibility
Datadog now offers deep, end-to-end visibility into your TeamCity builds with the new TeamCity integration for CI Pipeline Visibility.