Now a build configuration can be attached to multiple templates using the "Attach to template..." action menu. There is a new menu item in the Actions menu, Manage templates, allowing users to manipulate templates and build configurations. See details in our documentation.
Starting from this EAP, TeamCity comes with built-in Docker support. TeamСity-Docker integration provides the following features.
Adding the build feature will enable docker events monitoring: such operations as docker pull, docker run will be detected. The build feature adds the Docker Info tab to the build results page providing information on Docker-related operations.
TeamCity provides the Docker Wrapper extension for command-line, Maven, and Gradle runners. It is possible to specify a docker image which will be used to run command-line, Maven and Gradle build steps: TeamCity will start a container from the specified image and will try to run this build step within this container. All the details are written to the build log.
The runner allows building Docker images as a separate build step. When creating TeamCity projects/ build configurations from a repository URL, the runner is offered as build step during auto-detection, provided a Dockerfile is present in the VCS repository.
The runner allows starting docker-compose build services, and shutting down those services at the end of the build. A docker-compose YAML file with a description of the services to be used during the build is required. Both docker and docker-compose are required on the build agents.
In the future EAPs we are planning to allow users to configure authorized connections to specified Docker registries, enable automatic login/logout to the specified registry on build starting/finishing respectively, and provide clean-up of images pushed to a registry.
The future Java versions will enforce stricter call protocols for different Java modules, and it may cause issues (similar to the ones here and here) with XStream library which TeamCity uses heavily to deliver data from the build to the agent.
To ensure better compatibility with Java 9 and later Java versions, we changed the way the tests are reported from Ant builds, and TeamCity now uses service messages instead of the XStream-based network communication used by the previous implementation.
We have made every effort to preserve backwards compatibility, but if you have some custom reporting of service messages from your Ant builds, we’d appreciate if you tried running these builds with this EAP on your test server and report to us any issues which may occur.
There are several cases when a server restart can be required, e.g. when a new plugin is uploaded or deleted.
In this EAP TeamCity comes with the ability to perform the server restart from the UI. At the moment you can restart the server from the UI:
Using the Restart button on the Administration | Diagnostics page, Troubleshooting tab
Using the restart link on the Administration | Plugins List page when a plugin is added to / deleted from the server.
TeamCity has long provided the option to upload an external plugin via the UI. Starting from this EAP version, an external plugin can also be deleted using the corresponding option on the the Administration | Plugins List page.
Starting from this EAP, you can centrally manage NUnit console versions installed on agents using the Administration | Tools page. Different versions of NUnit 3 can be installed and the default version set/changed. The installed versions will be automatically distributed to all build agents.
Commit status publisher now supports Git repositories hosted in TFS/VSTS. Personal Access Tokens can be used for authentication. If a VSTS connection is configured, the personal access token can be automatically filled from the project connection.
Earlier, if you wanted to see your changes in an external system, you had to configure an external changes viewer per a VCS Root. Now TeamCity automatically recognized commits to GitHub, VSTS or Bitbucket and provides links enabling you to view the changes externally.
This EAP introduces new DSL API version
v2017_2. The previous API version
(v10) works and you can keep using it if you do not need the features provided by the new API.
The settings generated by TeamCity look like the settings in the previous TeamCity versions, the only difference is in the package name: it is
v2017_2 in the new version (the previous one is
There 2 main reasons why we introduce the new package: firstly, Kotlin 1.1 introduced a way to limit functions which are available in a particular scope, which allows having a better completion in the IDE. Secondly, the new API version provides the ability to validate settings before applying them to the TeamCity server. Plugins now mark their mandatory properties and TeamCity will reject settings from the VCS without such properties specified (e.g. a Git VCS root without the url). You can also provide a custom validation logic by overriding the
validate() method in your classes.
When versioned settings are enabled, TeamCity generates settings in the current DSL API version (v2017_2). If you need to generate settings for previous DSL API versions, you can use the 'Download settings in Kotlin format' action in the project administration area.
To try the new DSL API in a repository with an existing pom.xml, the maven dependency version has to be updated to 2
Now the TeamCity server provides html documentation for the core DSL API as well as the API provided by installed TeamCity plugins. The link to the documentation is located on the 'Versioned Settings' project tab. As before, the documentation in the IDE can be obtained by running the 'mvn -U dependency:sources' command locally.
Now the TeamCity server will restart automatically if the Java process of the server crashes.
The bundled Tomcat has been upgraded to 8.5.16
TFS Java SDK has been updated to 14.119.2, which removes compatibility with some environments: