See also Indore 10 EAP2 (build 41463) Release Notes

Project Settings Configuration Changes


Two-node Server Configuration



Several important notes about two-node configuration:


First of all, ensure that both machines where TeamCity software will be installed can access the same TeamCity data directory in read/write mode. For large installations we recommend using NAS. It is possible to share the directory using NFS, or Windows share, although the performance of such installation can be worse.



On the build messages processor machine, add additional arguments to the TEAMCITY_SERVER_OPTS environment variable:



Startup & shutdown


The build messages processor uses the same approach to logging as the main server. You can check how the startup is doing in the <TeamCity installation directory>/logs/teamcity-server.log file. You can also open <processor URL> in your browser, there you should see regular TeamCity startup screens.

Enabling Build Messages Processor


By default, the build messages processor is disabled and all traffic produced by running builds is still handled by the main server. Once you enable the build messages processor, all newly started builds will be routed to this node. The existing running builds will continue being executed on the main server.


On this page you can also see how many builds are currently assigned to each node. If the build messages processor is enabled, eventually all of the running builds will be switched to this node. 

Restarting Servers while Builds are Running

The build messages processor as well as the main TeamCity server can be stopped or restarted while builds are running there. If agents cannot connect to the build messages processor for some time, they will re-route their data to the main server. If the main server is unavailable either, agents will keep their data and re-send it once servers re-appear.

Upgrade & Downgrade


To upgrade:

  1. stop the build messages processor (if you forget to do that, you'll be warned during upgrade)
  2. start upgrade on the main TeamCity server as usual
  3. proceed with upgrade
  5. upgrade software on the messages processor machine to the same version
  6. start the messages processor and check that it is connected using the Nodes configuration page on the main server

To downgrade:

  1. shutdown the main server and build messages processor
  2. restore data from backup (only if the data format has been changed during upgrade)
  3. downgrade TeamCity software on the main server
  4. start the main TeamCity server and check that everything works
  5. downgrade TeamCity software on the build messages processor to the same version as the main server
  6. start the build messages processor

As usually with TeamCity, agents perform upgrade / downgrade automatically.


The TeamCity cleanup task runs on the main TeamCity server only. In a two-node configuration as well as in a single node configuration, it can work at the same time while the servers are handling data from the running builds.

Backup & Restore

Backup through TeamCity web interface can be done on the main TeamCity server only. Backup from the command line can be done on either the build messages processor or on the main TeamCity server.


Current limitations

Team Foundation Work Items Tracking




Cloud Support

VMware vSphere

Amazon EC2 

Email Verification 



During the project import TeamCity will take verified emails into account. If there are two users with different usernames, but the same verified email, TeamCity will provide a possibility to merge these users.

Exclude Patterns for Artifact Paths



+:**/* => target_directory
-:**/folder1 => target_directory


Project-bound Agent Management Permissions

Earlier granting agent-related permissions, like 'authorize' or 'enable'  could be done only globally (permissions were applied to all the agents on the server).

Now we introduce project-level permissions to perform a task on an agent: a user must have a specific permission granted in a project.

A user can perform a task controlled by one of these permissions on all the agents belonging to some pool provided this permission is granted to the user in all the projects associated with this pool. For example, a user with 'Enable / disable agents associated with project' permission in some projects can enable or disable agents which belong to the pools of the related projects if the permission is granted in all the projects associated with the pools.

The newly added permissions are:

The last permission and the recently introduced "maximum number of agents" setting for an agent pool enable you to set up the system in a way which allows project administrators to run new agents and authorize/add them to their pools without involving the global server administrator.

In new installations, these project-related permissions are added to the Project Administrator role. After upgrade, no permissions changes are applied, but you might want to review the permissions, e.g. consider removing the Agent Manager role inclusion from the Project Administrator role and adding the above-mentioned permissions to Project Administrator role manually.

Administration | Tools page improvements

In previous versions of TeamCity you could install a couple of predefined tools to TeamCity agents via the Administration | Tools page. In addition to that you could manually distribute zip archives to agents if you place them into special place on disk.

In addition, some of the plugins, like NuGet had own place for uploading new versions to agents.

In this EAP we unified all these tasks under the single interface. Now, you can manage NuGet versions, install recent version of ReSharper command line tools, or upload an arbitrary tool in a zip archive - all from the same Administration | Tools page.

Flaky Test Detection


Flaky test detection is based on the following heuristics:





New Create project / Create build configuration buttons



REST API Enhancements

DSL Changes


object Project_Sources : KVcsRoot({
    uuid = "uuid"
    extId = "Project_Sources"
    name = "Sources"
    param("usernameStyle", "USERID")
    param("reportTagRevisions", "true")


object Project_Sources : GitVcsRoot({
    uuid = "uuid"
    extId = "Project_Sources"
    name = "Sources"
    url = "http://acme.com/repo.git"
    branch = "refs/heads/master"
    branchSpec = "+:refs/heads/*"
    userNameStyle = UserNameStyle.USERID
    useTagsAsBranches = true

A similar DSL is provided for other plugins: mercurial, command-line, maven, gradle and others.  


Other Improvements