Agent Pools

If you have tens of agents shared between several projects you probably suffer from the following issues:

To solve some of these issues you could assign agents and build configurations one to one, but this would be a tedious and absolutely not scalable approach due to low granularity level.

TeamCity 7.0 addresses these problems in a more convenient way. You can distribute your agents among several agent pools and assign each project to a pool. A project can be assigned to more than one agent pool, but agent can reside in a single pool only. If a project is assigned to a pool, its builds can run on agents of this pool only. They won't affect other pools and other projects. There is also a so-called Default pool, that cannot be removed and serves as a place for all agents and projects not assigned directly to other pools.

Ability to perform one-to-one assignment between agents and build configurations is still there and provides a fine grained control within a pool.

Agent pools can be configured on the "Pools" tab under "Agents":

When you have agent pools configured you can easily monitor pools load on the agents matrix page:

If your project belongs to a single pool and there are no other projects in the pool, it is convenient to watch build queue for this pool only. This feature is also available:

Agent pools also affect compatible agents pages:

Learn more about agent pools

Typed build parameters

When defining a build parameter either on build configuration or project level, you can specify a type of a control for this parameter. For example, if a parameter has two values - true or false, it is natural to show it as checkbox. Currently this only affects custom build dialog.

Besides control type, you can also specify some standard properties for each parameter, such as:

Supported control types are:

If password parameter is used, TeamCity will do its best to hide the actual value of password parameter. You won't see the password in build logs, TeamCity web interface, or IDE plugins. It will be stored in configuration files in scrambled form. Note that as TeamCity performs global replacement of the password in build log, you have to choose relatively strong passwords - those that are unlikely to appear in the build log as a sequence of characters.

Parameter specification (a part of parameter which defines how to show it) cannot be overwritten if a parameter is inherited from a template or project.

Learn more about typed parameters

Build Chains

Build chains (a collection of builds combined by snapshot dependency) is a TeamCity approach to setting up something similar to a pipeline.
They first appeared in TeamCity 4.0 (released in November 2008) and have seen many improvements since then.

Some important notes:

Given the complexity of build chains, it is not easy to represent them visually. But we decided to make a first step in this direction in TeamCity 7.0.
We added a new "Build Chains" tab on project and build configuration pages. The tab shows build chains containing builds from the project or build configuration correspondingly. The tab looks like this:

For each build chain you can see all builds that constitute a build chain as well as their status: not triggered, in queue, running or finished. Clicking a build in a chain will highlight this build and all its direct dependencies (both upstream and downstream). Since there can be several build chain in a single project, there is an ability to filter them.

But this page not just visualizes the chain, but also provides some abilities you can't easily reproduce using earlier versions of TeamCity. For example, the following chain is in not triggered state:

This means some of the builds were not started yet. By pressing the "Run" button you can continue the chain, i.e a new build will be started on the chain revisions and associated with builds from this chain.
An  icon is shown for started builds only and opens the custom build dialog with build chain revisions preselected. This action can be used if you want to re-run some build in the chain.

Besides build chains presentation we've made some other important improvements.

Changes from dependencies

For a build configuration with snapshot dependencies you can enable showing of changes from these dependencies transitively. The setting is available on the "Version Control Settings" step of the build configuration administration pages:

Enabling of this setting affects pending changes of build configuration, builds changes in builds history, change log and issue log. Changes from dependencies are marked with . For example:

With this setting enabled, "Schedule Trigger" with a "Trigger build only if there are pending changes" option will consider changes from dependencies too.

Finish build trigger

Finish build trigger has become a little bit smarter too. If a build configuration is set up with a "Finish build trigger" and has snapshot dependencies to selected build configuration, the trigger will run the build on the same revisions and will attach the build to the chain. Thus you can have automated promotion of builds in a chain.

Build failure conditions

Newly added build configuration editing step called "Build Failure Conditions" accumulates all settings that define when the build should be marked as failed. Standard options like "fail build if at least one test failed" were moved from the "General Settings" step to this page.

Besides the standard options, you can find two new build failure conditions:

Fail build on metric change

With the help of this build failure condition you can track whether a specific statistical value changes within certain limits, and if it exceeds these limits, a build will be marked as failed. For example, you can require that the size of artifacts in your build is never less than 1Mb. Or that line coverage is always more than 80%.

There are cases when a build must be marked as failed if some statistical value differs significantly from a previous build (or from some reference build). For example, you may want to fail a build if the number of covered lines drops significantly compared to the previous build. Or, if compared to a build marked with some tag (reference build), the number of duplicate code fragments increased by more than a specified threshold. This is all possible with "fail build on metric change" condition.

Fail build on specific text in build log

The name of this failure condition speaks for itself. If text in the build log matches some regular expression, a build will be marked as failed. You can also define a failure message that will be shown in build status text and in the build log.

Learn more about build failure conditions

Incremental builds

Maven, Gradle and IntelliJ IDEA Project build runners now support incremental building (for IDEA it's limited to running tests). Say, your project has these modules: A-prod, A-test, B-prod, B-test.
Modules with -prod suffix contain production code, while modules with -test suffix contain tests for the corresponding production modules.

Now if a build starts with a change in module A-prod, TeamCity agent will run the tests in both modules (because B-test depends on A-prod and can be affected by the change).
However, if a change was made in B-prod only, TeamCity will only run the tests from B-test module.

In general, the more independent your modules are, the better. Modularity is a common good practice of software design, and now you can get another benefit from such approach: faster builds.

To enable this functionality for Gradle or IntelliJ IDEA project runners, simply turn on "Run affected tests only (dependency based)" checkbox. For Maven, you should enable "Build only modules affected by changes" checkbox.

Note that since IntelliJ IDEA project runner operates with run configurations instead of individual tests, when the "Run affected tests only (dependency based)" checkbox is enabled the runner will execute run configurations depending on affected modules only.

Read more about incremental building feature
Incremental building in Maven.


A long-standing feature request to allow build configuration editing via REST has finally been implemented.
Now you can get complete settings of a build configuration or template via REST and can also change them.
You can also create and delete build configurations, projects and VCS roots.

Here is an example of how to get build configuration steps:

curl -v --request GET http://user:pass@localhost:8111/app/rest/buildTypes/id:bt2/steps

Save individual step details to a file:

curl -v --request GET http://user:pass@localhost:8111/app/rest/buildTypes/id:bt2/steps/RUNNER_1 -o response.xml

And create a new step (a copy of the saved one):

curl -v --request POST http://user:pass@localhost:8111/app/rest/buildTypes/id:bt2/steps --data-binary @response.xml --header "Content-Type: application/xml"

REST API has had "/app/rest/application.wadl" since the very beginning, but it has now got an XML schema attached (see <ns2:grammars><ns2:include href="application.wadl/xsd1.xsd"> element and try application.wadl/xsd1.xsd request) and will hopefully get some more inline comments soon.

If you are already using the REST API please note that the protocol version has changed.

Additionally with TeamCity 7.0 REST API you can:

Learn more about TeamCity REST API


ReSharper Inspections

New Inspections runner for .NET is now available. Internally this runner uses parts of JetBrains ReSharper, so basically it means that ReSharper Code Analysis is now available on the server side too.
This runner helps you detect errors and problems in C#, XAML, XML, and ASP.NET code.

Key benefit of .NET Inspections runner is that it can use ReSharper 6.1 settings profiles. So you can easily tune the runner to match your own code style.

Inspection results are shown in the standard TeamCity interface.

Also, links to on-line inspections wiki are available for some inspection types.

Which should help you learn how the code can be improved.

Known issues

We still have a few unresolved technical problems which could lead to incorrect inspection results. All these issues will be targeted in the future releases. Among them:

Learn more about ReSharper inspections


NuGet is a relatively new tool in .NET world. In brief, it aims at solving dependency management issues experienced by many .NET projects. You can read more about NuGet on

TeamCity offers several NuGet-related features:

TeamCity as NuGet feed server

If you publish NuGet packages as TeamCity artifacts you can enable NuGet Server feature on Administration -> NuGet Settings page.

In this case TeamCity will provide its own NuGet feed with all published packages. You can use this feed in Visual Studio to get notifications when packages are updated on the server.

Learn more about TeamCity NuGet integration


Maven settings

Maven settings files often contain shared settings for all Maven-based projects within a company. Until TeamCity 7.0 it was hard to define them in TeamCity as you had to store these settings in version control (or on a network share), and remember to use command line options to specify a path to them. Now you can upload your settings files to TeamCity:

And then use them in Maven-specific build steps:

Bundled Maven 3

Maven 3 is now bundled with TeamCity in addition to Maven 2. You can select which Maven version to use in Maven build step.

Own local artifacts repository

In TeamCity 7.0 you can also isolate a specific build configuration artifacts repository from other local repositories. This can be done in one click on build step page.

Learn more about TeamCity Maven integration

Subversion 1.7 support

TeamCity 7.0 is compatible with Subversion 1.7:

Since IntelliJ IDEA does not yet support SVN 1.7, TeamCity plugin for IntelliJ IDEA also won't work with 1.7.

User interface & usability improvements

Several user interface improvements have been made in TeamCity 7.0.

Branch graphs in change log

Project and build configuration change log now shows branch graphs for distributed version control systems like Git or Mercurial.

There will be as many graphs as the number of VCS roots you have in your project or build configuration. When clicking a node in the graph, corresponding part of the change log is highlighted.

Also in places where information about committer is shown, TeamCity will try to show the TeamCity user name instead of the version control user name.

New administration area

We restructured the TeamCity administration area to make it more logical, scalable and to bring some often used pages up front.

Current problems & investigations

If you are assigned as investigator for some problem, a counter near your name will be updated:

Click on the counter will bring you to the "My Investigations" page:

Note that for each failed test on this page you can get a bunch of information instantly, without a need to leave the page. For example, you can see all build configurations in which this test is currently failing. You can also see a current stacktrace and information about a build where the test is currently failing. You can also see information about the first failure of this test, again with stacktrace and build.

Similar improvements were also applied to project's "Current Problems", "Investigations", and "My Changes" pages.

We also decided to get rid of Bulk investigation mode introduced in TeamCity 6.5. Instead, we always show checkboxes for investigation assignment or mute:

Build log tree view

Build log tree view has got several improvements:

You can filter build log by message priority, expand all nodes in the whole build log, or within a single node only. Tree view is now available for running builds as well (it was not so before TeamCity 7.0).

Artifacts browsing

Browsing inside artifact archives from within the TeamCity UI has become extremely easy. Supported archive types are: .zip, .jar, .war, .ear, .tar, .tar.gz, .apk, .sit. Browsing archives inside archives is supported too.

If you want to download a file from an archive in a build script, use this URL syntax:

http://<server url>/repository/download/<build conf id>/<build>/<archive>!<path in archive>

See more on this in our documentation

We also removed the "Base Path" field in project report tabs, as its only purpose was to handle paths inside archives.

Small, but noteworthy changes

Other improvements

Performance monitor

New "Performance Monitor" build feature can help you to track hardware resources used by your build. Upon build finish you'll see an additional tab called "PerfMon" with results like:

Here you can see that build produced zero CPU and Disk usage during a period of several minutes, starting at 15:00. Most likely there was some code spending a lot of time in wait state. By clicking a point in the chart, a part of build log for this period of time will be shown.

Performance monitor spawns a separate process which gathers hardware statistics. Statistics is gathered for the whole agent machine, so it won't work properly if you have more than one agent installed on the same machine and these agents run builds in parallel. CPU, Disk and Memory usage are all percentages of what is available on the agent. Sometimes you can see that only 50% of CPU is being used by a build. This usually means that a build does not utilize all CPU cores of the agent machine. Platforms supported by PerfMon are Windows, Solaris, Linux and MacOS X.

Per-check-in builds

VCS trigger now supports two new options:

With the first option enabled, each new check-in will result in a build added to the queue and associated with this check-in (i.e. build won't include other changes).

If the second option is enabled, and there are several pending changes, TeamCity will group them by user and will start builds having single user changes only.

Clean sources

Option to run a build with clean sources was added to custom build dialog and to "Schedule Trigger".

Build execution timeout

Global, per-server build execution timeout can be defined for all of the builds. If build configuration level timeout is specified, it will override the global setting.

Diagnostics page

Diagnostics page now shows current memory usage and JVM arguments. In case of memory issues (high memory usage for a prolonged period of time), a warning will be shown in TeamCity web interface. If you customized some TeamCity internal properties, you can see them on Diagnostics page too.

Artifact dependencies

Artifact dependencies now support syntax similar to checkout rules, i.e. you can define a set of new line delimited rules:

Enable / disable parts of build configuration

Settings like build triggers, build steps, build features and build failure conditions can be disabled in build configuration or template. Disabled settings will stay inactive until they are enabled again. If you disable a build step, this build step will not be executed on the agent. Inherited settings can be disabled too, for example, if a build step is inherited from a template, you can disable it in the build configuration and define some other step instead of inherited one.

Agent hardware information

Plugin providing information about agent hardware was available for quite some time (see We decided that it is useful enough to bundle it with TeamCity distribution.
The plugin provides the following parameters:

Artifacts cleanup

Ant-like file patterns can be specified for artifacts cleanup rules, in the form:

VCS username

VCS username, default for all of the types of version controls, can be specified on user profile.

Viewing personal builds of other users

To see personal builds of other users enable "Show all personal builds" setting on your profile.

Ruby environment configurator

First of all, the long standing bug with non-functional Ruby environment configurator ( has now been fixed.

Also, agents now detect the presence of RVM and report rvm_path environment variable with the path to RVM. This way you can easily set up your build configurations to run on agents where RVM is installed. Enabling of Ruby environment configurator will add this requirement automatically.

Previous Releases

What's New in TeamCity 6.5