Starting from this version, the free TeamCity Professional edition allows 100 build configurations per server.
The built-in TeamСity-Docker integration is now available.
TeamCity-Docker support can run on Mac, Linux, and Windows build agents.
The integration provides several features to facilitate working with Docker under TeamCity.
Docker Wrapper is an extension for Command Line, Maven, Ant, and Gradle runners enabling you to run the build step in an isolated Docker container. Each of the supported runners has a dedicated Docker settings section.
Docker Build 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.
Docker Compose Runner starts docker-compose build services and shuts down those services at the end of the build.
This build feature serves the following purposes:
Monitoring Docker events and providing information about Docker-related operations: the Docker Support build feature adds the dedicated Docker Info tab to the build results page.
Authentication to a Docker registry can be configured at the project level to be easily shared among builds. With this configured, you can use Docker Support to instruct the agent to automatically log in to a registry before the build and log out of it after the build.
It is also possible to enable automatic clean-up of images published by a build during the server clean-up.
Another clean-up-related feature of the integration is the ability of Free Disk Space to run the
TeamCity 2017.2 can now build, test, and deploy .NET Core projects out of the box: one of the highly popular TeamCity plugins, .NET CLI Support (aka .NET Core), is now bundled with TeamCity. The plugin has been significantly reworked and improved in terms of functionality and usability. It simulates the behavior of the dotnet command, which is fully supported out of the box now, and provides the following features:
Prior to TeamCity 2017.2, if you used build chains, there was no easy way to see whether the chain started or not. And if it did, you could not see failed tests and other build problems of the whole chain in one place. In addition, users often created a dedicated build configuration to aggregate artifacts of several builds in a chain and present them in a single place.
To ease this pain for the users, TeamCity now has the composite build configuration. Its purpose is to aggregate results from several other builds combined by snapshot dependencies and present them in a single place.
A composite build does not occupy an agent; it is shown as running at the same time when the first dependency of the build chain starts, and is shown as finished when the last dependency finishes. More details are available in our documentation.
TeamCity users often create build configurations performing deployment tasks. Such configurations usually have snapshot or artifact dependencies on the builds, whose results they deploy.
TeamCity 2017.2 allows you to mark such configurations as Deployment. After that, the builds they depend on, get the dedicated Deployments section on the build results page of this build, allowing you to quickly deploy the build:
More details are available in our documentation.
Upgrading your TeamCity server is much simpler now. When a new version of TeamCity is detected, the server displays the corresponding health item for system administrators pointing to the new Updates page in server Administration. The page lists all the related options as well as notes about licenses compatibility, the new version description and controls to perform automatic update. All you need to do is follow the instructions on the page. Details and limitations are described in our documentation.
The new options improve plugins management in TeamCity. There are now dedicated options on the Administration | Plugins List page to delete or disable plugins. Besides, if you upload a plugin, TeamCity will offer you to restart the server to apply your changes.
Now there is also the server Restart button on the Administration | Diagnostics page.
You can now use an existing template and set it as the default template of a project. After that, any template modification will automatically affect all build configurations in this project and its subprojects. Now it is much easier to add a specific build feature to all build configurations of a project, or switch all build configurations to some specific checkout mode, or provide a default failure condition.
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.
This TeamCity version provides several features, requested by the users, most wanted being the ability to edit settings via the TeamCity Web UI and Kotlin DSL documentation.
Earlier, when Kotlin DSL was enabled for a project, the administration part of the TeamCity user interface used to be read-only which was challenging if you just started working with Kotlin projects.
Now when you switch a project to the Kotlin DSL, project and build configuration settings will be available for editing from the web UI. All changes made in a project via the UI will be presented as a patch in the Kotlin format which will be checked in under the project “patches” directory. Details and limitations are described in our documentation.
If you are already using Kotlin DSL, to use editing from the UI, you need to migrate to the new DSL API version.
Now after Kotlin DSL is enabled for a project, the TeamCity server provides html documentation for the core DSL API as well as the API provided by installed TeamCity plugins. The documentation is accessible via the link on the 'Versioned Settings' project tab in the UI or by running the
mvn -U dependency:sources command in the IDE.
Other benefits of migrating to the newer version of DSL API include:
validate()method in your classes.
TeamCity 2017.2 comes with polished web UI, bringing you a number of improvements. We also unveil a set of pages which use components built with React and serve data provided by the TeamCity REST API.
The All Builds page allows server administrators view and filter finished builds. By default, the builds can be filtered by build status: Successful, Failed, Canceled and Failed to start, as well as by project or build configuration. Since the results are obtained via the TeamCity REST API, all build locators are supported by the advanced search options.
This page is especially useful right after the upgrade of the server. Using this page, system administrators can find recently failed builds faster, which in turn helps to identify compatibility problems which may occur right after the server upgrade.
The Agents page is also built using the data provided by the TeamCity REST API and boasts a new, fresh look. The page is optimized to work fine with hundreds of agents and not to load the browser CPU.
TeamCity REST API new capabilities and improvements include:
"affectedProject"or multiple values of the
Be informed that starting from v14.114.0, Microsoft removes support for the following environments:
What's New in TeamCity 2017.1