Up until this EAP there were three options how project settings could be configured in TeamCity. The straightforward way - via the web UI, using REST API, or via XML files if versioned settings feature is enabled.
In this EAP we introduce another way - ability to define settings programmatically with help of DSL based on Kotlin language.
Kotlin based DSL can be seen as an evolution of the versioned settings, with it you can define your configuration in Kotlin language, without the need to use XML files.
Since Kotlin is statically typed, you automatically receive auto-completion feature in IntelliJ IDEA which makes discovery of available API options a much simpler task.
To get started with Kotlin DSL navigate to Versioned settings menu option for your project and choose kotlin as settings format:
After that TeamCity will generate necessary Kotlin files for this project and check-in them into the specified repository under .teamcity directory. If this repository already had project settings in XML format, they will be preserved.
TeamCity also adds pom.xml file under .teamcity directory. You can open this POM in your IntelliJ IDEA and start working with Kotlin DSL right away. All necessary dependencies will be resolved automatically.
From this point you can write your own code in Kotlin language, using API provided by TeamCity Kotlin DSL. Internally, TeamCity still operates with XML. So once you make a change in .teamcity TeamCity will run your Kotlin scripts and will produce XML files. These XML files then will be applied to existing project. In case of any problems (compilation failures, runtime errors, etc), new changes will not be applied, and current project settings will be preserved on the server.
Traditionally TeamCity uses polling for detecting changes in VCS repositories. Polling is a highly reliable approach suitable in the majority of cases. Even if the TeamCity server was stopped for a while, with polling it can easily pickup all the changes made in repositories on the next startup.
But polling has one downside which becomes more and more important, as TeamCity installation grows. If there are many different VCS repositories configured in TeamCity, polling can impose significant load on both TeamCity server and VCS repository servers.
The alternative approach is to use the push model: various post commit hooks and web hooks. This approach is more scalable, but it cannot be used alone: if the TeamCity server is stopped, obviously all push notifications will be lost.
This is why we decided to implement a combined approach. Starting with this EAP, if a commit hook initiates the process of checking for changes for some VCS root in TeamCity, TeamCity will automatically increase checking for changes interval for this VCS root, assuming that this commit hook will now come to TeamCity on a regular basis. But, if so happens that TeamCity detects a change in this VCS root during regular polling, then the checking for changes interval will be reset to the initial value specified by the user when the VCS root was created. This is done for the case when a commit hook stopped working for some reason. If the TeamCity server was restarted, it will switch to polling for all of the VCS roots, till commit hooks start informing it about new commits.
Please refer to our documentation on commit hooks configuration in various VCS repositories.
It is now possible to export configuration files for a project with its children as a zip archive to move it to a different TeamCity server. The Project Settings | Settings Export page allows exporting the config files for a project and its subprojects, as well as external dependencies, i.e. build configurations used in snapshot dependencies, templates used as well as vcs roots and all main settings (ssh keys, issue trackers, oauth connections etc...) defined in the parent project.
The settings archive also contains a
report.log file detailing the reasons for exporting external entities.
The Commit status publisher build feature now supports GitLab thanks to an external contribution.
If you use Perforce jobs to label your commits, the changes associated with jobs are now marked with a "wrench" icon in the TeamCity UI. Navigating to the icon opens a pop-up with the job information:
In this EAP projects and build configurations as well as collapse/expand actions received new icons. Overall, the UI boasts of a refreshed look and feel.
TeamCity comes with built-in support for many of issue trackers, which now include Bitbucket cloud. The integration with Bitbucket cloud issue tracker can be set up separately, or as a part of TeamCity integration with Bitbucket source code hosting service making it easy to connect TeamCity to Bitbucket issues.
With the latest REST API version it is now possible to:
TeamCity now has support for Git LFS if checkout on agent is used.
performance of the project and build configuration settings editing has been greatly improved
you can now redefine inherited artifact dependencies in build configurations, the same as agent requirements and other settings