Child pages
  • Jaipur 2018.1 (build 58158) RC Release Notes

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 more simpler format of Kotlin DSL settings. When we designed it, we had the following goals in mind:

  • we wanted to make Kotlin DSL scripts simpler
  • we wanted to make it possible to share Kotlin DSL scripts between different servers
  • we wanted to 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 (there is 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 now is enabled now enabled by default when the Kotlin format is selected.

Making Kotlin DSL look simpler

With the new format instead of the following 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 by  the object ID. If the object ID changes, then the build configuration history can become temporary 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 how what this file looks like for a very simple project:

...

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

Changing the build configuration ID

There is no ID in the generated script sbove 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:

...

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

Where where you can select the one which belongs to your configuration.Note: if

Note

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, all we have about 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.

...

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

This essentially allows to use 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: https://youtrack.jetbrains.com/issue/TW-3287

Currently еру 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:

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

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

  • The bundled .NET Tools (dotCover and ReSharper CLT) have been updated to the latest released version 2018.1.2.

  • All fixed issues TODO