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:

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

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:

object MyBuildType : BuildType({
    uuid = "<some uuid>"
    id = "MyBuildType"
    name = "My build configuration"
 ...
});

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

object MyBuildType : BuildType({
    name = "My build configuration"
 ...
});

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:

import jetbrains.buildServer.configs.kotlin.v2018_1.*
import jetbrains.buildServer.configs.kotlin.v2018_1.buildSteps.script 
version = "2017.2" // this version will be changed in the final 2018.1 version 
project {
    buildType(HelloWorld)
} 
object HelloWorld : BuildType({
    name = "Hello world"
    steps {
        script {
            scriptContent = """echo "Hello world!""""
        }
    }
})

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:

object HelloWorld : BuildType({
    id("MyBuildConf")
    name = "Hello world"
...
})

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 {
    buildType(HelloWorld)
}

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:

var deployTarget = if (DslContext.projectId == AbsoluteId("Trunk")) {
    "production"
} else {
    "staging"
}

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

Other Improvements