New in TeamCity 2018.2: Show Kotlin DSL for Build Configurations

The Kotlin-based DSL is becoming more popular for defining build configurations in TeamCity. We are continuing to improve the user experience for Kotlin, both in the TeamCity UI and the IDE plugin.

Once the versioned settings option is enabled for the project, we recommend making new changes in the Kotlin configuration rather than in the UI. However, it might be tempting to make the changes in the UI instead of figuring out how to define something in Kotlin. For such occasions, we have added a little UI helper to assist with the DSL definitions.


TeamCity 2018.2 introduces a new option in the UI to help anyone who uses the Kotlin DSL. You will find the new “View DSL” toggle in build configuration settings in the UI. Click the toggle to view the Kotlin DSL definition. The DSL representation opens and highlights the setting in focus.


Check out the screencast demonstrating the new feature in action:

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

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

Missed the webinar? No problem – the recording of our January 8 webinar, What’s New in TeamCity 2018.2, is now available.

In this webinar, Anton Arhipov showcases the major features of the latest release. He goes over the secondary node setup and explanation, building GitHub pull requests, showcases the simplified installation of plugins, previewing Kotlin DSL configuration in the UI, automatic assignment of investigations, and metadata in tests.

Enjoy watching and feel free to share with your friends and coworkers.

Q&A from the session

Q: Can secondary server node feature be used for migration to another server (add secondary, remove primary)?
A: Read-only (available in 2018.1 already) node can to some extent. We also plan to cover the use case when further extending the multi-node setup.

Q: The example shown for secondary nodes had both servers running on the same computer. Is this required, or can the secondary node be on a different system? And if it can be different, can it be on a different OS (Linux/Windows, etc.)?
A: They can be installed on different machines. Different OSes are also supported. It is required to share the data directory somehow (Windows SMB or Linux NFS will work). Still, it makes sense to have the same OS for both servers to simplify the setup.

Q: Does the Agent and/or Server restart when installing new plugins?
A: The server loads the plugin without restart. Since this plugin brings in an agent part, that agent part is automatically downloaded by all the agents and the agents are restarted automatically. This agent update just takes some time.

Q: When an Agent restarts, is it rebooting the machine or stopping and starting the TeamCity agent service?
A: Only the TeamCity agent service is restarted. The Agent restarts and updates without the whole machine restart.

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

New in TeamCity 2018.2: Metadata in Tests

Ever since TeamCity 2018.2, a test run in TeamCity can be associated with some supplementary information (metadata), in addition to a test’s status, execution time, and output. This information can be used to provide things like extra logs, screenshots, numeric values, and tags.

You can now use service messages to report this kind of additional test data in TeamCity and then view it using the TeamCity Web UI. Consult the corresponding documentation for details.

On GitHub, you can find a sample project that demonstrates the use of metadata with tests. In TeamCity, create a project from the URL using this GitHub repository, and then run the build. Once the build completes, on the Tests tab, next to the test name, you will notice a staple icon indicating that the test results include additional metadata.


By clicking the icon, you will open a popup displaying the attached metadata. The same information is presented on the build overview screen. Notice that a numeric value renders a 2D-graph from the historical results.


In the demo project, see CodeTest.kt for the examples of the metadata reporting code.

Posted in Blogroll, Features, Tips&Tricks | 2 Comments

New in TeamCity 2018.2: Increased Scalability

TeamCity 2018.1 allows you to set up a “running builds node.” The node handles data coming in from the build agents. There’s also the “read-only node” for handling disaster recovery scenarios.

TeamCity 2018.2 expands this setup further, making it possible to delegate polling of version control systems to a secondary node.

Currently, it may seem a little complicated, but our intention is simple. We want to have a scalable architecture where you can add more nodes to the cluster so that all the nodes are uniform and can perform all the tasks in an interchangeable way. The only exception will be the main TeamCity server where we configure the cluster. Upgrade, licensing, and diagnostics are also handled by the main TeamCity server.

As a step towards this uniformity, there is no “read-only node” anymore, and it is now called a “secondary node.”

The secondary node is just a TeamCity server started with the additional nodeId argument:
TEAMCITY_SERVER_OPTS=-Dteamcity.server.nodeId=<some id> teamcity-server.bat|sh start

See our documentation on how to configure and start a secondary node.


By default, the secondary node acts as a read-only node. It does not change any data, but only shows the user interface in read-only mode. This setup is well-suited for disaster recovery tasks.

Using the Nodes configuration page of the main TeamCity server, it is now possible to delegate VCS repositories polling responsibility to this secondary node. After that, the secondary server will handle all VCS polling related tasks and commit hooks. In some scenarios, this can greatly reduce the CPU load of the main TeamCity server.

Note that if there are existing commit hooks on the main server, you do not need to change anything. The main server will accept the hook and delegate its processing to the secondary node.

Right now, the secondary node cannot handle data from agents like the running builds node can. But this will change in the future versions of TeamCity. Agents’ data handling will be another responsibility for the secondary node.

Posted in Blogroll, Features | Tagged | Leave a comment

TeamCity 2018.2.1 is out

Today we’re announcing TeamCity 2018.2.1, a bug fix update for our recently released version.

This version fixes about 100 issues, most notably upgrade-related problems. Besides, LDAP authentication now works properly when a trusted certificate is added to the TeamCity server. Several important UI improvements have been made as well; the full list is available in our release notes.

We strongly recommend upgrading, as this build also addresses some TeamCity performance issues.

As usual, TeamCity 2018.2.1 update has the same data format as all 2018.2.x versions, allowing you to upgrade / downgrade easily within these builds.

Remember to check our Upgrade Notes and use one of the upgrade options:

We appreciate your feedback in our forum or tracker.

Happy holidays and happy building!

Posted in Bugfix, Release, Uncategorized | Tagged | 2 Comments

TeamCity 2018.1.5 is here

Today we’re releasing the TeamCity 2018.1.5, the last bug fix build for the previous TeamCity version.

Although TeamCity 2018.2 is already out, we’re rolling out this update as it addresses a few important issues; see all of them listed in our release notes.

As any TeamCity update, 2018.1.5 has the same data format as all 2018.1.x versions, allowing you to upgrade / downgrade within these builds easily.

Remember to check our Upgrade Notes and use one of the upgrade options:

We’ll appreciate your feedback in our forum or tracker.

Happy building!

Posted in Bugfix, Release | Leave a comment

Webinar: What’s New in TeamCity 2018.2

Join us January 8, 2019, 5:00 PM – 6:00 PM CET (11:00 AM – 12:00 PM EDT) for our free live webinar, What’s New in TeamCity 2018.2.


In this webinar, Anton Arhipov will go over the new major features of the latest TeamCity 2018.2. You will see:

  • How to set up a secondary node for collecting changes from VCS.
  • What TeamCity now offers for working with GitHub pull requests.
  • How installing and updating plugins from the plugin repository has been simplified.
  • Why adding screenshots and other data to test results can provide more insight.
  • How previewing Kotlin DSL code for project and build configuration settings can simplify adopting the configuration as code paradigm.
  • How automatic investigation assignments help notify the right team members of a build failure.
  • When you should enforce build steps and requirements in templates.

Space is limited, so 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 JetBrains TeamCity. His professional interests include everything Java, but also other programming languages, middleware, and developer tooling. A Java Champion since 2014, Anton is also a co-organizer of, a local developer community in Tallinn, Estonia.
Posted in Features, Webinar | Tagged | Leave a comment

TeamCity 2018.2 released: secondary node, GitHub pull requests, improved plugin experience, screenshots in test results, and Kotlin DSL previews

Please welcome TeamCity 2018.2 – this year’s second major release. With this version, outsource collecting VCS changes to a secondary node, build GitHub pull requests, and install plugins without restarting the server. Screenshots in test results, automatic investigation assignments, and multiple NuGet feeds round out the picture.


Here is an overview of the main new features of the release.

Increase scalability with a secondary TeamCity node

The secondary TeamCity node is designed to take the load off the main TeamCity server by taking over the task of collecting and checking for changes from the Version Control Systems. Outsource the collecting of VCS changes to the secondary node to increase the scalability of your whole installation. It is also possible to use the secondary node for a high-availability setup.

Screen Shot 2018-12-05 at 16.38.46

Build GitHub pull requests

TeamCity has extended its support for GitHub pull requests. Filter the pull requests by author and limit them to internal or external collaborators, or open them for everyone. There is also the option to filter pull requests by target branch.

Enjoy working with plugins

  • Install from the plugin repository. You can now browse and install plugins in TeamCity directly from the JetBrains plugin repository.
  • No server restart. Once a plugin is installed from the plugin repository, you no longer need to restart the TeamCity server for it to be applied.
  • Hassle-free plugin development. Similarly, when developing a plugin for TeamCity, there is no need to restart the server anymore.

Add screenshots in test results

TeamCity 2018.2 lets you add screenshots and other test data, such as links, artifacts, logs, and numeric values, to the test results. These will be displayed natively in the test details section of the UI.


Preview settings in Kotlin DSL

Unsure how best to describe a setting in the Kotlin DSL format? TeamCity now automatically generates DSL code for all your settings and lets you preview it in the admin UI. Handy for learning DSL format or for just copying parts of DSL to insert into already existing settings.kts file.

Assign investigations automatically

You can now let TeamCity suggest or automatically assign investigations to team members based on a number of heuristics. That way the person who most likely broke a build will receive a notification to investigate the failure.


Multiple NuGet feeds

TeamCity 2018.2 lets you specify multiple NuGet feeds to be used by builds in a project and all its subprojects. It also introduces support for NuGet Server API v3.


There is more to this release! See the detailed description of these and other features in the What’s new section in our documentation.

Download TeamCity 2018.2

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.

Also, sign up for our free webinar on January 8, 2019, to see the new features in action.

Posted in Features, Release | Tagged | Leave a comment

TeamCity 2018.2 RC is released

TeamCity 2018.2 release candidate is out today.

This build contains about 70 fixes; it comes with numerous updates for bundled tools and brings several UI improvements.

Remember that TeamCity RC builds come without the EAP license, but the license for the previous EAP release is valid for this RC version as well.

See our release notes for details, and download Jaipur 2018.2 RC build. It is important that you install it on a trial server as the new version will modify the data format, but downgrading is not supported.

Your feedback is always welcome in our forum or tracker.

Stay tuned for the latest news: the new version is on the way!

Happy building!

Posted in EAP, Release, Uncategorized | Leave a comment

TeamCity 2018.1.4 is released

The new bug fix version, TeamCity 2018.1.4, is available. We have solved over 40 bugs:
you can see the full list of the fixes in our release notes.

We recommend upgrading, as this build addresses TeamCity security and performance issues, and includes important UI performance improvements.

As with any update, TeamCity 2018.1.4 has the same data format as all 2018.1.x versions, allowing easy upgrade / downgrade within these builds.

Remember to check our Upgrade Notes and use one of the upgrade options:

Your feedback is welcome in our forum or tracker.

Happy building!

Posted in Bugfix, Release | 3 Comments