Unable to render embedded object: File (TeamCity48.png) not found.

TeamCity 10.x and 2017.x Documentation


You are viewing the documentation of TeamCity 10.x and 2017.x, which is not the most recently released version of TeamCity.
View this page in the latest documentation or refer to the listing to choose the documentation corresponding to your TeamCity version.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Besides storing settings in XML, TeamCity allows storing project settings defined in the Kotlin language. Using DSL based on the Kotlin language enables you to define settings programmatically, without the need to use XML files. Since Kotlin is statically typed, you automatically receive the auto-completion feature in IntelliJ IDEA which makes discovery of available API options a much simpler task.

On this page:


Advantages of Kotlin DSL vs XML

The Kotlin settings format provides higher level of abstraction, and better code reuse.

  • Build configurations often share settings and need to be different in few aspects only. For example, when you need to test your software against different platforms, let's take an ORM framework to be tested against different databases, then the builds running tests are mostly the same, the only difference is the part configuring a database connection.With Kotlin, you can extract the common part and reuse it across all builds which ensures that the common part does not change and makes maintaining builds easier.
  • Kotlin also allows you to describe your setup in terms of your domain. For example, TeamCity provides generic requirements for build agents and you can define requirements specific to your installation:

    then you can use them in a build configuration:

Getting Started with Kotlin DSL

Learning Kotlin

The Kotlin tutorial helps you learn most Kotlin features in a few hours.

Downloading Settings in Kotlin

To start working with Kotlin DSL, go to the project settings page, click the Actions menu and select Download settings in kotlin format. This will generate a .zip archive with project settings which can be used in your sandbox project.

When you have familiarized yourself with Kotlin, you can use the Kotlin-based DSL for project settings in production.

Using Settings in Kotlin in Production

  1. Enable versioned settings for your project.
  2. Select kotlin as the format.
  3. Commit the settings to your version control.  Once the project is switched to Kotlin, editing of the project settings is disabled in the UI (except a few pages: Versioned settings, Maven Settings, SSH keys and Meta-runners), as currently there is no way to propagate changes made via the web UI to Kotlin DSL files. 


    Note:  If you need to enable editing, switch versioned settings to XML format or disable versioned settings.

  4. Once you apply the versioned settings to your project, TeamCity will generate necessary Kotlin files for this project and check them in to the specified repository under the .teamcity directory. If this repository already had project settings in the XML format, they will be preserved, but TeamCity will no longer use them:  once you get familiar with Kotlin files, these xml files can be removed.

Working with Kotlin DSL

The .teamcity folder contains a maven project consisting of pom.xml file and  the <Project External Id> directory with the settings.kts and Project.kt files, as well as buildTypes, pluginData, and vcsRoots subdirectories. If the project contains subprojects, they will be placed in the directories with corresponding names.

Opening Project in IDE

Open the pom.xml in your favourite IDE and check that the URL of the teamcity-server repository points to your TeamCity.

If the server url is correct and your TeamCity is up and running, all necessary dependencies will be resolved automatically and you can start working with Kotlin DSL right away.



The TeamCity server does not use the pom.xml file; it is used by the IDE to download required dependencies and to provide code completion as well as detect compilation errors, so any changes you will make to this POM file won’t have any effect during the DSL processing. You can also delete this file.

Essential Files


The settings.kts script is an entry point for defining a single TeamCity project. TeamCity looks for the settings.kts file in a project directory and runs it if it is found, so the script name must not be changed and its package must be the same as the project's external id.

The script should contain a single call to the project() function with a Project instance or an init function as an argument, you can also specify both of them to refine the specified Project in the init function.


This file contains the project definition.

 Vcs roots, Build types, and Templates of this project must be registered inside the  project using the vcsRoot(), buildType(), and template() methods respectively.

Subprojects can be defined either in their own settings.kts or by calling the subProjects() method in this project.

As this is a Kotlin code, you are free to  add conditions, loops, methods, classes, etc.

Required Identifiers

All TeamCity entities - project, build configuration, VCS root and template have a so-called uuid. The uuid is an identifier which can be used to uniquely distinguish this specific entity from others. If at some point the entity receives a new uuid, it is considered a new entity by TeamCity. For instance, if the build configuration uuid changes, the builds history of this build configuration will become empty (if you change it back before cleanup, the history will be restored). The same rule applies to a project - if its uuid changes, the project will lose its investigations and muted tests. We suggest selecting some naming scheme for uuids in your project and never changing them. 

There is also the extId field which is mandatory. The extId is used to represent build configuration (or template) ID / vcs root ID, project ID in the web UI; it is also used in the DSL to reference other entities. Besides, it is used in various links (such as build configuration links) and REST API.  

Making Changes to Project Settings

Once project is switched into the Kotlin DSL format, we recommend the following approach for changing the project settings:

  1. Set up unit tests.

  2. Create a dedicated project on your TeamCity server to run these unit tests.

  3. Create a separate branch/repository and run tests on your changes there. 


    Avoid pushing changes right into the branch monitored by TeamCity without running any tests, as it can affect your project and all of the users currently working with this project  

  4. If the tests are green, merge the changes into the default settings branch. 


    To merge the branch automatically if the build is green, consider using the TeamCity automatic merge build feature.

Creating New Project

You can create a new project via DSL inside a parent project which already has uses settings in the Kotlin format. A new project can be added either in its own directory with settings.kts or using the subProject() method in the parent project. 

Apply your changes as described in the section below.

Applying Changes to TeamCity

 When you have made changes to your Kotlin DSL code, сommit your code into the .teamcity directory containing your project settings. 



Currently, no external resources are supported. Please also note that pom.xml is not used on server, so any libraries that you might want to add will be ignored during DSL processing. 

TeamCity will apply the changes to  configuration as follows: 

  1. TeamCity will detect the commit, execute Kotlin DSL files and produce new configuration files. Since internally TeamCity operates with XML, TeamCity will execute DSL files in a secure sandbox to produce XML configuration files. These XML files then will be applied to the existing project.
  2. TeamCity will apply the new configuration files to the project effectively changing its configuration. In case of any problems (compilation failures, runtime errors, etc.), new changes will not be applied, and the current project settings will be preserved on the server and the error message will appear under the Versioned Setting tab in project settings.
  3. The builds will  run with the new settings.

 Note that:

  • The Kotlin script is executed on the server, and since this is a potentially dangerous operation, the script is executed in the sandbox. It cannot modify the file system except the place where it is executed, it cannot run other programs, cannot use reflection, and so on.
  • The Kotlin DSL is experimental, and the provided API may change in future versions.

Common Problems

New URL of Settings VCS Root 

 Problem: I changed the url of the VCS root where settings are stored in Kotlin and now TeamCity cannot find any settings in the repository at the new location.


  1. Fix the url in the Kotlin dsl in the version control and push the fix.
  2.  Disable versioned settings to enable the UI.
  3.  Fix the url in the VCS root in the UI.
  4.  Enable versioned settings with same VCS root and the Kotlin format again, TeamCity will detect that the repository contains the .teamcity directory and ask if you want to import settings. 
  5. Choose to import settings.

Do not Commit Passwords

Problem: I do not not want the passwords to be committed to the VCS, even in a scrambled form.

Solution: You can move the passwords to the parent project whose settings are not committed to a VCS.

Change Passwords after Settings Generation 

Problem: I want to change passwords after the  settings have been generated.

Solution:  The passwords will have to be scrambled manually using the following command in the  maven project with settings:


See also:

















  • No labels