What's New in TeamCity 7.0

Search

Searching TeamCity 7.x Documentation

Table of Contents

Agent Pools

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

• there are no agents available for your project because all of them are used by builds from other projects;
• you cannot easily change software on agents because it can affect not only your builds but builds from other projects too;
• it is not easy to predict whether builds from your project will gain some benefits if more agents are added to the system.

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:

• label - custom label to display for this parameter in custom build dialog
• description - text to be shown under the control in custom build dialog
• display type: normal, hidden or prompt. If hidden is specified, parameter will not be shown, but will be sent to a build; if prompt is specified, TeamCity will always require a review of parameter value, even when you trigger a build by simply clicking the "Run" button; if normal is selected, parameter will be shown as usual

Supported control types are:

• text field
• checkbox
• select
• password

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:

• each build chain is a directed acyclic graph, i.e. build chain cannot have cycles
• all builds in a chain will have either the same revision, or, in case of several VCS roots, revisions corresponding to changes made at the same moment of time
• if a build depends on another one by a snapshot dependency it means the build cannot start until the dependency finishes
• several build chains can have common builds. For example, in order to reduce build chain execution time, TeamCity can decide to merge some build chains, if the results of a previous chain can be reused in a subsequent chain

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
• Fail build on specific text in build log

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.

REST API

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:

Save individual step details to a file:

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

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 class="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:

• change project level parameters
• authorize and disable agents and get parameters reported by an agent
• change user properties (e.g. VCS usernames)
• pause build configurations
• get content of a file from VCS using revisions of a build

Learn more about TeamCity REST API

Integrations

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:

• in order to have adequate inspections execution results it might be necessary to build your solution before running analysis. This pre-step is especially relevant when you use (implicitly or explicitly) code generation in your project, see TW-19220.
• currently you could face with problems if you use MSBuild properties in your project files, see TW-19678.

Learn more about ReSharper inspections

NuGet

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 NuGet.org.

TeamCity offers several NuGet-related features:

• keep an up-to-date NuGet version on all agents and on TeamCity server
• new build runners
  • Nu