Branch specific settings in TeamCity

We’re often asked how to run different build steps in different branches. In fact, this has already been possible in TeamCity for quite some time (since version 9.1), but it seems we need to do a better job explaining how to use this feature.

Let’s assume that you have a build configuration where building of feature branches is enabled.

First, enable Versioned settings for the project where this build configuration resides. TeamCity will ask for a VCS root where the settings are to be stored. For simplicity’s sake, let’s store the settings in the same VCS repository where other project files are located.

For the Versioned settings, make sure the option When build starts is set to the use settings from VCS value. TeamCity will then take the settings from a branch used by the build instead of the current settings.


Once versioned settings are enabled, TeamCity will commit the .teamcity directory with the current project settings to the default branch of the selected VCS root. To start customizing the settings in our feature branch, we need to merge the .teamcity directory from the default branch.

But before making any changes in the .teamcity directory in your feature branch, bear in mind that not all the changes there will be applied. For instance, if you add a new project or a build configuration, such changes will be ignored. This happens because TeamCity does not support different sets of projects and build configurations in feature branches.

Besides, there is a chicken and egg problem. Currently TeamCity loads settings from .teamcity while the build sits in the queue. But to load the settings from a repository, TeamCity needs to know this repository settings (VCS roots). Thus VCS roots are always taken from the current project settings.

The same story is with build triggers and snapshot dependencies. TeamCity needs triggers to decide when to place builds into the queue. And TeamCity needs snapshot dependencies to create a build chain (graph of builds) before the builds are going to the queue. Hence the changes in .teamcity affecting these settings are ignored too.

But there are plenty of other settings whose changes will affect the build behavior:

  • build number pattern
  • build steps
  • system properties and environment variables
  • requirements
  • build features (except Automatic merge and VCS labeling)
  • failure conditions
  • artifact publishing rules
  • artifact dependencies

By default, the settings are stored in the XML format. Since there is no publicly available documentation for this format, it is hard to guess how to change build steps correctly, or how to add a build feature. This is what a command line build step looks like in XML:

What can help here is seeing how TeamCity generates these settings. For instance, get a sandbox project on your TeamCity server for such experiments, and browse the audit page for settings difference after each change:


Another option is to use Kotlin DSL (see the Settings format option on the Versioned settings page). In this case, instead of .xml files, .kt files will be stored under the .teamcity folder.

A Kotlin DSL project can be opened in IntelliJ IDEA Community (free and open-source IDE from JetBrains). Kotlin DSL files look much more concise, and IDE auto-completion makes it much easier to work with them, especially in the recent TeamCity versions. This is what the same command line build step looks like in Kotlin DSL:

Some additional hints:

  • Since TeamCity 2017.2 you can browse Kotlin DSL documentation using the following URL: <TeamCity server URL>/app/dsl-documentation/index.html
  • If a build loads settings from the VCS repository, you should see something like this in the build log:
  • Actual settings used by the build are stored in the buildSettings.xml file under the hidden build artifacts. This file can be helpful if something does not work as expected.
  • If you’re using remote runs instead of feature branches, then all the same abilities are also available, provided that the .teamcity directory is  present in your repository and versioned settings are configured as described above.

Finally, one more thing to keep in mind. If changes under .teamcity in your feature branch were temporary, you should not forget to revert the settings during the merge with the default branch. For instance, if you removed some long running steps or switched off some tests for convenience.

Happy building!

Posted in Features, How-To's, Tips&Tricks | 3 Comments

Webinar recording and Q&A: What’s New in TeamCity 2017.2

The recording of our December 20 webinar, What’s New in TeamCity 2017.2, is now available on the JetBrains YouTube channel.

In this webinar, Wes Higbee goes over the new features of TeamCity 2017.2, the latest release of TeamCity. He demonstrates how the Docker-specific build runners and the new Docker support build features work; the built-in .NET CLI support for building the .NET Core projects; the new composite builds for aggregating build results; as well as the default and multiple templates.

Continue reading

Posted in Features, Webinar | Tagged | Leave a comment

TeamCity 2017.2.1 is released

Today we are releasing an update for the latest TeamCity version, TeamCity 2017.2.1.

This is a bugfix release fixing over 100 issues. For details please see the Release notes.

Upgrading is strongly recommended if you are using with TeamCity. As will deprecate a number of older cryptographic standards in February 2018, this change will affect agent-side checkout in all TeamCity versions before 2017.2.1 and server-side checkout in TeamCity versions prior to 9.0.2. If upgrading is not possible for you, see this workaround.

Other users are also advised to update to this version as it features a number of important fixes.

TeamCity 2017.2.1 has the same data format as all the 2017.2.x releases, which means that downgrading is possible if required.

If you are already using TeamCity 2017.2, use the Updates page for an automatic update.

Update 1721

To upgrade from older versions, download TeamCity 2017.2.1 and install it on your server.

We’ll appreciate your feedback: feel free to use our forum and tracker.

Happy building!

Posted in Bugfix, Release | Tagged | Leave a comment

What’s New in TeamCity 2017.2, December 20th Webinar

Join us Wednesday, December 20th, 16:00 – 17:00 CEST (10:00 AM – 11:00 AM Eastern) for our free live webinar, What’s New in TeamCity 2017.2 with Wes Higbee.

r (1)

In this webinar, Wes Higbee will go over some of the major features of the latest TeamCity release. He will demonstrate how the Docker-specific build runners and the new Docker support build features work; the built-in .NET CLI support for building the .NET Core projects; the new composite builds for aggregating build results; as well as the default and multiple templates.

Space is limited, so please register now. There will be an opportunity to ask questions during the webinar.

About the presenter:

Wes McClureWes Higbee is passionate about helping companies achieve remarkable results with technology and software. He’s had extensive experience developing software and working with teams to improve how software is developed to meet business objectives. Wes launched Full City Tech to leverage his expertise to help companies rapidly deliver high quality software to delight customers. He has a strong background in using Continuous Integration with TeamCity to bring quality to the table.
Posted in Features, Webinar | Leave a comment

TeamCity Support for AWS EC2 Container Service

TeamCity has been able to run build agents on AWS EC2 instances for ages.

In addition to this, the new plugin for TeamCity, Amazon ECS Support, allows running Docker-based build agents in an EC2 Container Service cluster.

The plugin is compatible with TeamCity 2017.1.x and later.
First, download the plugin and install it on the TeamCity server as usual.

Next, create a cloud profile in your project


Specify the AWS region and enter credentials to access AWS API and test your connection.


To make the plugin work, the provided credentials need the IAM role with the following permissions granted:

  • ecs:DescribeClusters
  • ecs:DescribeTaskDefinition
  • ecs:DescribeTasks
  • ecs:ListClusters
  • ecs:ListTaskDefinitions
  • ecs:ListTasks
  • ecs:RunTask
  • ecs:StopTask

Finally, create a cloud image which will correspond to the build agent configuration you need by specifying the task definition, cluster to run build agent tasks, and agent pool for your agents.


In contrast to using EC2 as a cloud provider (which allows using almost infinite computation resources with no additional configuration required), using the TeamCity ECS plugin in production requires the ECS cluster to be configured properly.
The following aspects should be considered:

  • Cluster capacity (cpu, disk)
  • Cluster scale in and scale out
  • Security
  • Build agent logs collecting
  • etc.

To make it a bit easier, we’ve published the Terraform template we are using on our side to set up the infrastructure for TeamCity TestDrive build agents.

Even when configured properly, the ECS cluster will likely be limited in terms of available resources. So, when TeamCity tries to start one more cloud build agent in the cluster, there might be no CPU or RAM available. You can specify the “Max cluster CPU reservation” percentile in the cloud image to make TeamCity stop running new cloud agents when the CPU reservation limit is reached. This requires the additional AIM role: cloudwatch:GetMetricStatistics.

Feel free to download the plugin and try it on your server, or give the plugin a test drive in the cloud. Please share your feedback with us!

Happy building with TeamCity!

Posted in Features, FYI | Comments Off on TeamCity Support for AWS EC2 Container Service

TeamCity 2017.2 is released!

We are thrilled to announce that TeamCity 2017.2 has been released today!

First of all, we’d like to thank all our users who helped us make the product better:
it really means a lot to know that you are willing to take time and report your success or problems, that you venture to try out our pre-release versions, that you are as excited about the new release as we are. We, the TeamCity team, really appreciate this.


Now let’s talk about the TeamCity licensing news: the TeamCity Professional license increased the number of build configurations, and instead of the 20 you are now entitled to 100 build configurations with our free version!

Why we decided to increase it? We believe that as projects and teams grow, they can get more and more benefit from TeamCity and take advantage of the features which are visible on larger-scale installations. For instance, with a limit of 20 build configurations, there is a little chance you’ll be able to put to full use such features as snapshot dependencies, Kotlin DSL, templates or even projects hierarchy. Not to mention that the modern trend towards microservices architectures also requires a larger number of different build configurations.

Next, this release is packed with new features; most of them have been already announced in our early access program for TeamCity 2017.2, so here is the summary:

  • The built-in TeamСity-Docker integration is now available for agents on Mac, Linux, and Windows. The integration provides a number of features to facilitate working with Docker under TeamCity.
  • Out-of-the-box support for .NET CLI: you can now build, test, and deploy .NET Core projects
  • Aggregated results from several build configurations can be now obtained using Composite builds
  • Deployment build configurations make it easier to deploy and redeploy the results of the builds such configurations depend on
  • Easy TeamCity server upgrade with the new automatic update option
  • and much more, including the improved UI.

The detailed description is available in the What’s New.

Download the brand new TeamCity 2017.2 and check the Upgrade Notes before you install the new version!

Don’t have the time and resources to set up a test server? Test drive the latest version of TeamCity in the cloud.

We always carefully consider your feedback and you are most welcome to use our forum or tracker.

Happy developing and building!

Posted in Features, News & Events, Release | 7 Comments

TeamCity 2017.2 RC is here

Greetings, everyone!

We are pleased to announce the release candidate for TeamCity 2017.2. We’ve been mostly focusing on polishing the new features and tackling issues, so this is essentially a bugfix release.

Build #50444 addresses over 100 problems, listed in our release notes.

TeamCity 2017.2 RC is still work in progress, and it changes the TeamCity data format so be sure to install it on a trial server as downgrading is not supported. You can try the new automatic update feature or download the TeamCity 2017.2 RC build and install it as usual.

This may be your last chance to report issues on this preview version, as we are planning to release TeamCity 2017.2 next week.

Your feedback will be greatly appreciated: feel free to post it here in comments, in our forum or tracker.

Follow us for the latest news on the upcoming release.

Happy developing and building!
The TeamCity Team

Posted in Bugfix, EAP | Comments Off on TeamCity 2017.2 RC is here

TeamCity 2017.2 EAP4 is available

Greetings, everybody!

Today we are happy to announce TeamCity 2017.2 EAP4.

We have fixed about 110 bugs and worked on several new features, including:

  • .NET CLI plugin
  • Deployment type for build configuration
  • REST API / React pages
  • Kotlin DSL improvements

There’s more: details on these and other features, as well as the full list of fixes are available in our release notes.

Try this TeamCity version: either upgrade to the new EAP automatically or download the TeamCity 2017.2 EAP4 build as usual. As with every major TeamCity version, this release changes the TeamCity data format so make sure to install it on a trial server.

Your feedback is welcome here in the comments, on our forum or tracker.

Happy building!

Posted in Bugfix, EAP, Features | Comments Off on TeamCity 2017.2 EAP4 is available

TeamCity Kubernetes Support Plugin

Kubernetes nowadays is quite a popular way to run Docker containers. A number of teams and organizations already have a Kubernetes cluster configured and used in production.

Now with the help of the TeamCity Kubernetes Support plugin, it is possible to use the same infrastructure to run TeamCity build agents.

The plugin is compatible with TeamCity 2017.1.x and later.

First, download the plugin and install it on the TeamCity server as usual.

Then you can start by configuring a cloud profile in a project:


Specify the URL of the Kubernetes API server (aka Kubernetes master), select the appropriate namespace.

Select one of the Kubernetes API authentication options:


The next step after connecting to the Kubernetes API is creating a cloud image.


There are two options available:

  • Simply run single container: good choice for those who don’t know about all the powerful Kubernetes features but want to simply run its container;
  • Use pod template from deployment: will handle all the possible advanced scenarios of configuring workload to a Kubernetes cluster like multi-container pods, node/pod affinity and toleration, etc.

When the “Simply run single container” mode is selected, users can specify the name of the Docker image with the build agent they want to use.

In our setup, we are using the official TeamCity Build Agent image which is supported by the plugin. You can also create your own image.

Other options like Docker command, Docker arguments, and image pull policy, will be useful as well.


Another cloud image option is ‘Use pod template from deployment’.

Here you simply specify a deployment name: remember to check that the deployment belongs to the same namespace you’ve provided in the cloud profile. You can either use the official TeamCity Build Agent image in your deployment like in the example below, or your own image.


There is a small trick here. When given a deployment name, the plugin will not actually use it as deployment, but it will extract the PodTemplateSpec section from its definition and use it to create the plugin’s own pods. The plugin’s own pods means that the pods will not be connected to deployment anyhow. The Kubernetes deployments feature will not be used to manage the pods’ lifecycle. The TeamCity server will take care of those pods on its own. Deployment will be used as a container of PodTemplateSpec which can be referenced by name.

After a cloud profile is created and saved, you will be able to start TeamCity agents running in containers in the scope of the pods on the Kubernetes cluster. TeamCity will mark every started pod with a set of specific labels.


Using those labeled pods, you can always determine which TeamCity server started a particular pod, which cloud profile and cloud image are affected.

Feel free to download the plugin, try it, and share your feedback with us!

Or you can TestDrive it in the cloud.

Happy building with TeamCity!

Posted in Features, FYI, How-To's | 8 Comments

Welcome TeamCity TestDrive – a simple way to try TeamCity in the cloud

For a couple of weeks now, there has been a new button on the TeamCity website:

Screen Shot 2017-10-25 at 13.22.35

Clicking it allows you to access TeamCity in the cloud, hosted by JetBrains. We call it TeamCity TestDrive.

What is TestDrive?

TestDrive is a limited cloud TeamCity offering. It is a way to try TeamCity for 60 days, without the need to download and install it. TestDrive is currently hosted on top of server, and lets users create one TeamCity project. It is free but it has some limitations with regards to the software that’s on the build agents.

Why you should care

Have you ever had a project in GitHub, which you’ve always wished could be used with TeamCity, but weren’t sure whether it would be worth it? Or have you wanted to demo TeamCity to your colleagues or your boss, but never had the time or the resources to install it on a server? Or have you simply searched for an easier and faster way to try it? We believe TestDrive will help you with all the above, here is why:

Use TeamCity in the cloud, without installation
TestDrive is a great way to try TeamCity without the hassle of downloading and installing it on a server. It is hosted by JetBrains and runs just like any regular TeamCity would.

Set up and run your project in TeamCity for 60 days
You can set up a single project in TeamCity by simply providing a link to your version control system. After that, you have 60 days to work on it.

Export your project data
After the 60-day period elapses, or any time earlier, you can create a project export, which you can then import into a regular on-premises TeamCity, should you wish to continue working on it.

Invite collaborators
Send invitations to other people to join your TeamCity project.

It’s free
That’s it. We charge nothing for using TeamCity TestDrive.

Try TeamCity TestDrive

Some of the most frequently asked questions:

If I like it, can I continue using TeamCity in the cloud?
There is no hosted TeamCity offering provided publicly yet. The main purpose of TestDrive is to provide you with an opportunity to try TeamCity for 60 days. After that, we encourage you to download TeamCity. The default Professional edition is free.

Will I have dedicated Build Agents for my project?
The Build Agents which run all the TestDrive builds are shared among several projects, so the Build Agent time will be distributed proportionally between them. Depending on the load, there is a chance that build times might increase during peak hours.

Which software is available to me? Can I install my own?
The software on Build Agents is provided by JetBrains. Linux-based agents are currently available. Review the full list of installed software.

Do I have to wait until the end of the 60-day period to export my project data?
You can export your data at any time and use it for a regular on-premises TeamCity. After the 60-day period expires, your data (project and build configuration settings) will be stored on our servers and available for export for another 30 days, and then deleted.

What will be exported?
Exporting from TestDrive works exactly like a regular TeamCity project export. Currently, only project and build configuration settings are exported. Your builds, artifacts, test history, changes, users and groups are not exported.

Got feedback, questions, requests, or just want to reach the team behind TestDrive? Contact us via the feedback form.

Posted in Features, FYI, Release | 6 Comments