Child pages
  • Jaipur 2018.1 (build 58158) RC Release Notes
Skip to end of metadata
Go to start of metadata

See also 

Jaipur 2018.1 (build 57985) EAP2 Release Notes
Jaipur 2018.1 (build 57605) EAP1 Release Notes

Server independent / simplified Kotlin DSL format

The upcoming 2018.1 version of TeamCity will support a much simpler format of Kotlin DSL settings. When we designed it, we had the following goals in mind:

  • make Kotlin DSL scripts simpler
  • make it possible to share Kotlin DSL scripts between different servers
  • allow reusing the same Kotlin DSL script by several projects on the same server

To achieve all of these goals, we added a new setting (enabled by default), which produces the simplified version of Kotlin DSL:

  • for the simplified version, TeamCity generates a single settings.kts file if a project is relatively small
  • Kotlin scripts in the simplified version do not have uuids (there are important consequences of this decision, more on this later)
  • the simplified Kotlin scripts do not have the id, instead the id is taken from the Kotlin class name
  • the versioned settings themselves are not stored in the simplified version of Kotlin DSL (they contain no definition of VCS root, or the versioned settings feature)

Enabling the simplified format

The simplified Kotlin DSL format is enabled if the checkbox "Use relative IDs" is selected:

Note: this option is now enabled by default when the Kotlin format is selected.

Making Kotlin DSL look simpler

Compare the old definition of a build configuration:

With the one TeamCity generates now, using the simplified format:

In this case the ID of "My build configuration" will be taken from the class name. As to the uuid, TeamCity will try to locate it by the object ID. If the object ID changes, then the build configuration history can become temporarily unavailable. But do not worry, you can restore it via the web interface.

In this simplified format TeamCity also generates a single settings.kts file with all project settings. So this is what this file looks like for a very simple project:


The project does not have either ID or name. Both the ID and name come from the TeamCity server. You can access them in a script, but you cannot change them. These settings essentially define the context where the script is being executed. In turn, it allows reusing the same script for different projects.

Changing the build configuration ID

There is no ID in the generated script above for the HelloWorld build configuration. The ID is taken from the class name. If you want stricter control on it, you can use id function like this:

But since there is no uuid in this format, once the ID is changed, the TeamCity server will think that this is a new object, meaning that previous builds history of this configuration won't be shown anymore. It is still possible to restore this history via the special menu action of the build configuration:

You will be presented with the user interface listing all recently deleted build histories

where you can select the one which belongs to your configuration.


If the builds history is important, you should not delay restoring it, because after a few days, the clean-up process will remove the history with all of the builds, as it does in case of any other deleted build configuration.

Project context

In the example above, everything related to the current project looks like this:

project { } represents the current project where the DSL will be executed. This is the project where versioned settings are enabled. This project ID and name can be accessed via a special DslContext object.

Based on the context, the DSL script can generate slightly different settings, for instance:

This essentially allows using the same Kotlin DSL script for different projects. Actually this is similar to what our users wanted, when they asked us to implement project templates.

Currently the project context is quite limited, but we have plans to extend it in the future. For instance, we think about adding project parameters there, so that the DSL script could make decisions based on the parameter value instead of ID or name.

Create project from URL

As we can see, the simplified format of Kotlin DSL supports reuse of the same script among different projects on the same server. This allows us to finally support it in the create project from URL feature.

So now, when you start creating a project from URL, TeamCity will scan the repository for presence of .teamcity/settings.kts file and, if the file is found, it will offer to import the settings from Kotlin DSL:

Now it is possible to put TeamCity settings along side with some project sources in a public VCS repository and then share a link to this repository, so that others could easily restore these settings on their own servers.

TeamCity Docker Integration Improvements

The improved integration includes

  • Support for multiple Docker Compose YAML file(s): the path to the docker-compose.yml file(s) should be relative to the checkout directory. When specifying several files, separate them with a space
  • Support for AWS ECR (Elastic Container Registry) in Docker plugin

Other Improvements

  • Custom certificates store is now supported for TFS
  • The new option to copy build numbers has been added to the Copy project dialog

  • You can add a description to templates now
  • The bundled .NET Tools (dotCover and ReSharper CLT) have been updated to the latest released version 2018.1.2.

  • SSL certificates uploaded to the server are now transferred to agents automatically
  • All fixed issues






  • No labels