TeamCity 2018.1.2 is released

We are happy to announce TeamCity 2018.1.2, the bugfix update containing over 100 fixed issues in various areas of TeamCity. The changes are mostly related to

  • Kotlin DSL
  • Performance
  • Security (several new XSS’s were fixed)

Besides, starting from this version TeamCity supports several read-only nodes running simultaneously.

The complete list of fixes is available in our release notes.

Check the Upgrade Notes before you install the new version and do not hesitate to upgrade: version 2018.1.2 has the same data format as all 2018.1.x builds do and makes it possible to upgrade/downgrade between these versions.

TeamCity offers several upgrade options:

Your feedback is welcome in our forum or tracker.

Happy building!

Posted in Bugfix, Features, Release | 10 Comments

New in TeamCity 2018.1: Inherited build steps configuration improvements

There is sometimes a need to define a common build step in a template, so that this step will be executed either before all build configuration steps or after them.

Here’s a simple example. I’m building a lot of typical Maven projects, and for most of the part their build is the same: just run mvn clean package and upload the binaries to the maven repository. However, for some of the builds, I need the additional steps to run in between mvn package and mvn deploy.

In TeamCity, the requirement above can be implemented with the aid of Build Configuration Templates. Starting with version 2018.1, for a given template it is possible to define build steps and then define their placement in respect to build steps defined in a build configuration. The build configuration steps are represented as a placeholder in the Reorder Build Steps dialog. The template steps can be placed before or after this placeholder.


This looks like a neat solution to the problem I described above! :)

Even more: it is possible to override the inherited build steps right in the build configuration. For the rare occasions, it makes sense! For instance, what if for one of the build configurations I want to upload the binaries to some different repository than the one defined in the template? I could just add altDeploymentRepository parameter to the build step – voila!


The build step will be marked as overridden in the list of all steps of the build configuration.

Posted in Blogroll, Features, Tips&Tricks | Tagged , , | Leave a comment

New in TeamCity 2018.1: Enforced settings

Enforcing some rules in a project might be quite useful to keep the things in order. For instance, enforce agent side checkout everywhere, or make sure that all build configurations have some strict execution timeout, or enable build files cleanup (Swabra) for all the builds.

Starting with 2018.1, TeamCity provides the ability to enforce settings for all of the build configurations in a project hierarchy.

To enforce some settings in the project hierarchy, a template with these settings must be created. After that, a system administrator can set this template as the enforced settings template in the project:


To some extent, the enforced settings template works similarly to the default template – i.e., build configurations inherit all of its settings in the project hierarchy. The difference is that these inherited settings cannot be disabled or overridden anyhow.

In addition to that, only system administrator can associate a project with a specific enforced settings template, project administrator permissions are not sufficient. So it makes sense to store the enforcement template in a place that is only editable by a system administrator, for instance – in a Root Project.

On the other hand, the template itself can be edited by a project administrator who can administer the project where the template is defined. If the enforced settings template is specified in a project and another template is assigned as the enforced settings in a subproject, the subproject’s template has the higher priority.

Currently it is not possible to enforce VCS roots, build steps, triggers, dependencies and requirements. Let us know if you see valid use cases when this would be useful.

Posted in Blogroll, Features | Tagged , | Leave a comment

New in TeamCity 2018.1: Project Level NuGet feed

TeamCity integrates with NuGet package manager and can also serve a NuGet feed. Using TeamCity as a NuGet feed comes handy if you want to publish your NuGet packages to a limited audience – just to your team, for instance.

Before TeamCity version 2018.1, NuGet feed was global for the whole server. And it was only possible for the system administrator to enable the feed.

Having a global feed could lead to a substantial size, delays with packages appearance, etc. TeamCity 2018.1 addresses those issues by allowing to enable a NuGet feed at the project level, which means each project can have a dedicated feed. As a consequence, the project administrator has the authority to enable the feed, which reduces the administrative overhead.


By default, TeamCity no longer adds all .nupkg artifacts to the project feed. To index packages published by selected build configurations only, add the NuGet packages indexer build feature to these build configurations.


Alternatively, to index all .nupkg files published as build artifacts in the project, enable Automatic NuGet Packages Indexing on the NuGet Feed page of the project settings.

Posted in Blogroll, Features | Tagged , | Leave a comment

TeamCity 2018.1.1 is here

A month has passed since we published TeamCity 2018.1. During this month we tirelessly processed feedback from you fixing the regressions that we accidentally introduced in 2018.1. We’re very grateful to our users who installed version 2018.1 and reported bugs back to us. Your patience and willingness to improve the product are very much appreciated!

2018.1 indeed broke a few things. For instance, a major problem was found in the NuGet feed implementation, some users experienced problems with the “History” builds appearance after the upgrade, the agent side checkout with Git did not work in some cases, etc.

All these problems and many others have been fixed in the current version, 2018.1.1. This build also brings fixes in Kotlin DSL, memory usage optimizations and a few performance fixes. See the list of all fixed issues in our Release notes.

As usual with bugfix releases, TeamCity 2018.1.1 has the same data format as 2018.1 does, making it easier to upgrade/downgrade between these versions.

If you’re using a recent version of TeamCity, consider using our automatic upgrade. In other cases, you can download the new version from the website or pull the new version of the TeamCity docker image.

Your feedback is welcome in our forum or tracker.

Happy building!

Posted in Bugfix, Release | 2 Comments

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

Missed the webinar? No problem – the recording of our July 10 webinar, What’s New in TeamCity 2018.1, is now available.

In this webinar, Anton Arhipov showcases the major features of the latest release. He goes over the significantly reworked TeamCity Kotlin DSL and shows how projects can be set up programmatically, from just one settings file. The High Availability TeamCity setup with a read-only node installation is also explained. Finally, the revamped Docker support with the updated Docker runner is demonstrated, as well as the bundled Amazon S3 artifacts storage.

Q&A from the session

Kotlin DSL

Q: Where can I learn more about the language used for DSL?
A: The language is Kotlin:

Q: Is there a way to define meta-runners using Kotlin DSL instead of XML?
A: Not at the moment. They are present in repository as XML files. But the point of meta-runners is to provide the ability to reuse steps. In Kotlin you can write a function which defines the steps, so probably you don’t need meta runners there at all.

Q: Do existing settings and builds defined in the Kotlin language in TeamCity 2017.2 get automatically updated to the new version or is 2018.1 backward compatible with existing declared Kotlin build pipelines and settings?
A: They will continue working as before. Since this is code, manual changes should be done to migrate DSL to the new version. First of all, the package should be changed to v2018_1, then compilation errors should be fixed. The version in settings.kts should be changed too. Here is documentation on how to perform the migration:

Q: What would the TeamCity behavior be if we have a project configured in Kotlin with active branches and the snapshot dependencies are changed in settings.kts for a branch which is not the default branch (for example a feature branch which adds a new build configuration to the build chain, but isn’t merged to master yet)?
A: Before triggering a build chain in a branch, TeamCity already needs to know how this chain is configured. So it can take these settings only from the current project settings. It can’t load them from the branch. So snapshot dependencies are always taken from the current project settings (basically, loaded from the default branch of the settings VCS root).

Q: Is there support for subprojects in Kotlin DSL?
A: Yes, there is.

Q: Can we specify the checkout rules for VCS builds?
A: Yes, you can specify all the same setting that you have in the TeamCity web interface.

Q: Can I use this settings.kts file and execute the steps locally on dev environment to mimic TeamCity?
A: Unfortunately, not. The DSL generates configuration, it does not execute anything. It generates new config files, which are applied to the project and then you can run builds with new settings.

Q: How the plugin details /settings are configured in settings.kts file?
A: All the settings can be configured by supplying a set of text properties: everything which can be configured in the TeamCity settings XML can be done via the DSL. Plugins can also provide typed API to DSL to get DSL completion for their settings configuration.

Q: Do we have a stages-like model similar to Jenkins?
A: The pipeline in TeamCity is declarative, not imperative. You define a set of configurations combined by dependencies. The server decides how to execute this pipeline, in which order, etc. Depending on the settings, requirements, available agents.

Q: Can we define different snapshot and artifact dependencies in different branches?
A: You can store different settings.kts files in different branches and create different projects from them. But in a single project, you can’t have a different set of configurations or different dependencies.

Q: Can the build configuration differ per branch or is it always loaded from the default branch? For example, can pull requests also build with a new configuration?
A: By default, server loads settings from the branch specified in the VCS root. It is possible to configure the server to load settings from the branch where the build is executed, but there are limitations. You can’t for instance, have a different set of projects or build configurations, as well as different snapshot dependencies.

Read-only node

Q: Data directory can contain certificates/ssh keys – is that not a risk of adding in NAS?
A: Data directory contains all the settings necessary to access the repositories, the data should be protected with due permissions.

Q: Is there a license cost for a read-only TeamCity server?
A: No, you can run the read-only node without any extra licenses.

Anton ArhipovAnton Arhipov is a Developer Advocate for TeamCity at JetBrains. His professional interests include everything Java, but also other programming languages, middleware, and developer tooling. Java Champion since 2014. Anton is also a co-organizer of, a local developers community in Tallinn.
Posted in Features, Webinar | Tagged | 6 Comments

What’s New in TeamCity 2018.1, July 10th Webinar

Join us Tuesday, July 10th, 5:00 PM – 6:00 PM CEST (11:00 AM – 12:00 PM EDT) for our free live webinar, What’s new in TeamCity 2018.1 with Anton Arhipov.


In this webinar, Anton Arhipov will showcase all the major features of the latest TeamCity 2018.1. We will go over the significantly reworked TeamCity Kotlin DSL and show how projects can be set up programmatically, from just one settings file. The High Availability TeamCity setup will be demonstrated using a read-only node installation. Finally, we will look into the revamped Docker support with the updated Docker runner, as well as the bundled Amazon S3 artifacts storage.

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

Register for the webinar

Anton ArhipovAnton Arhipov is a Developer Advocate for TeamCity at JetBrains. His professional interests include everything Java, but also other programming languages, middleware, and developer tooling. Java Champion since 2014. Anton is also a co-organizer of, a local developers community in Tallinn.
Posted in Features, Webinar | Tagged | Leave a comment

TeamCity 2018.1 released: revamped Kotlin DSL, read-only server, new Docker runner, and bundled S3 integration

Please welcome TeamCity 2018.1 – the first major release for TeamCity this year! This version gives you significant improvements in Kotlin DSL, revamped Docker support, native integration with Amazon S3 for storing artifacts, and High Availability installation possibilities.


If you took part in our recent EAP (Early Access Program), you may have already heard of the new functionality this release has in store. If not, here’s a quick overview:

New TeamCity Kotlin DSL

  • Simple. The DSL format is now simpler and more readable. No more uuid or project IDs.
  • Single file. One settings.kts file is now all you need to describe the project settings.
  • Portable. DSL scripts are now server and project independent.
  • Create from URL. Just point TeamCity to the repository with the settings.kts file, and it will spin up projects and build configurations as described in code.

High-Availability setup

Set up a highly available TeamCity installation with the new read-only server mode. The read-only server has access to the database and the data directory, and in the event of the main server becoming unavailable, will accept all the requests and allow read access to the builds, artifacts, etc.

Revamped Docker support

  • The Docker wrapper now supports .NET CLI and PowerShell runners, allowing you to run those build steps inside a Docker container.
  • build, push, and other Docker commands are available directly in the new Docker runner, which replaces the old Docker Build Runner.

Amazon S3 artifact storage

Storing, uploading, downloading, and removing artifacts from S3 is now integrated natively and can be done via the TeamCity UI.

There is more to this release! Enforced settings, improvements in templates, ability to upload a trusted SSL certificate, and UI updates. See the detailed description of these and other features in the What’s new section in our documentation.

Also, sign up for our free live webinar on July 10th to see the new features of 2018.1 in action.

Download TeamCity 2018.1

Please check the Upgrade Notes before you install the new version, and do not hesitate to report any issues in our tracker, or ask questions in the forum.

Happy building!

Posted in Features, Release | Tagged | 2 Comments

Welcome Jaipur 2018.1 RC

Today we’re announcing TeamCity 2018.1 release candidate.

This build contains over 150 fixes, improvements in support for Docker, but most importantly it comes with simplified Kotlin DSL format for TeamCity settings.

If you ever wanted to try Kotlin DSL for TeamCity settings but you were put off by its complexity, now it’s time to change your mind, as we considerably reworked it.

Remember that TeamCity RC build comes without the EAP license, but you can still use the license for the previous EAP release.

Check out our release notes, download Jaipur 2018.1 RC build, make sure to install it on a trial server: TeamCity 2018.1 will modify the data format and the downgrade is not supported.

Your feedback is always welcome in our forum or tracker.

Stay tuned for the latest news – the release date is approaching!

Happy building!

Posted in EAP, Release | Leave a comment

Rust plugin for TeamCity

Rust is an interesting programming language with decent tooling support. Cargo is an official build tool and a package manager for Rust programs. So what if you use Rust and want to configure automated builds in TeamCity? No worries, we have it covered! You can download the Rust and Cargo support plugin and install it as an additional TeamCity extension.

The plugin is compatible with TeamCity starting from version 10. It relies on rustup for managing the Rust toolchain.

The plugin detects the Cargo.toml configuration file once you add a VCS root to the Build Configuration, and suggests the corresponding build steps.

For the Cargo build step, it is enough to define just the name. However, multiple additional options are available under the “Show advanced options” link. For instance, it is possible to specify which packages and features the step should include, and which toolchain version should be used.

During the step execution, the plugin monitors the console output of the command. The summary is then displayed in the TeamCity UI: which tests were executed, how long it took every individual test to run, which tests were ignored, etc.

You can now build Rust programs with TeamCity and feel good about it! The plugin sources are available in the  GitHub repository and we are happy to receive your feedback in our forum and tracker!

Happy building!

Posted in Blogroll, Features | Tagged , , | Leave a comment