What's New in TeamCity 2018.1

Portable Kotlin DSL format

TeamCity 2018.1 supports a much simpler format of Kotlin DSL settings - portable DSL. It allows sharing of the same Kotlin DSL scripts between different servers and even reusing the same Kotlin DSL script by several projects on the same server.

The portable Kotlin DSL has the following properties:

in the portable format, TeamCity generates a single settings.kts file
by default Kotlin scripts in the portable DSL do not have ids (both uuid and id are optional)
the versioned settings themselves as well as the definition of a VCS root where the settings are stored are not available in the portable Kotlin DSL and cannot be changed via DSL

In this simplified format, TeamCity also generates a single settings.kts file with all project settings. 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 = "2018.1" 
project {
    buildType(HelloWorld)
} 
object HelloWorld : BuildType({
    name = "Hello world"
    steps {
        script {
            scriptContent = "echo 'Hello world!'"
        }
    }
})

See details in our documentation.

Create Project from URL recognizes Kotlin DSL settings

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

Read-Only Node

TeamCity makes a step towards High Availability by introducing a read-only mode for the server. It is now possible to start a second, read-only TeamCity server, that allows users read operations, such as view the build information, download artifacts, etc. during the downtime of the main server, e.g. during an upgrade.

The Read-Only node uses the same Data Directory and the same external database as the main TeamCity Server, so a prerequisite of using the Read-Only node is to ensure that it has access to the data directory and database.

Using a read-only node in addition to the main TeamCity server, it's possible to set up a highly available TeamCity installation that will have zero read downtime, i.e. when the main server is unavailable or is performing an upgrade, requests will be routed to the read-only node. Such setup requires installing both the main server and the read-only node behind a reverse proxy, that should be configured to proxy requests to the main server while it's available and to the read-only one in other cases.

Note that an additional server in a high-availability set-up uses the license from the main server and does not require a separate license .

Details are available in the dedicated documentation section.

User Interface Changes

The build configuration home page has been redesigned (internally it now uses the REST API to show its data)

Besides, TeamCity uses the new artifacts icon to indicate the presence of artifacts in a build.

Uploading SSL / HTTPS Certificates

TeamCity now allows uploading a trusted certificate, e.g. be a self-signed certificate, or a certificate signed by a not well-known certificate authority (CA). The uploaded certificate becomes trusted by TeamCity, which means TeamCity will be able to open a connection by HTTPS or SSL protocols to a resource with this certificate. Currently, the trusted certificates storage is global for the whole server and affects all of the server projects.

See details in our documentation.

Inherited build steps configuration improvements

Ability to have pre- and post-steps in a template

There is sometimes a need to define a common build step in a template so that this step will be executed either before all build configuration steps or after them.

Starting with this version, for a given template it is possible to define such steps and then define their placement in respect to the build configuration steps. All build configuration steps are represented as a placeholder in the Reorder Build Steps dialog. The template steps can be placed before or after this placeholder.

Note: you still can have a completely custom order of steps in a build configuration inherited from a template.

Ability to redefine inherited build step settings

Starting with this version it is possible to change inherited build steps right in the build configuration.

Enforced settings

TeamCity now provides the ability to enforce settings for all of the build configurations in a project hierarchy. For instance, with the help of this feature, it is possible to enforce agent side checkout everywhere or make sure that all build configurations have some strict execution timeout.

To enforce some settings in the project hierarchy, a template with these settings must be created. After that, a system administrator can set this template as the enforced settings template in the project:

To some extent, the enforced settings template works similarly to the default template - i.e. all of its settings are inherited in build configurations of the project hierarchy. The difference is that these inherited settings cannot be disabled or overridden anyhow. In addition to that, only the system administrator can associate a project with a specific enforced settings template - project administrator permissions are not sufficient. On the other hand, the template itself can be edited by a project administrator who can administer the project where the template is defined.

If the enforced settings template is specified in a project and another template is assigned as the enforced settings in a subproject, the subproject's template will have a higher priority.

Currently, it is not possible to enforce VCS roots, build steps, triggers, dependencies, and requirements. Let us know if you see valid use cases when this would be useful.

Project Level NuGet Feed

In previous versions of TeamCity, NuGet feed was global for the whole server. Not only that, but once the feed was enabled, TeamCity started indexing of all of the .nupkg files published as artifacts. On a large server this could lead to a really large feed, delays with packages appearance, increased disk usage for the feed metadata and sometimes very low performance which was one of the most common complaints in the past.

It is now possible to enable a NuGet feed at the project level, which means each project can have its own NuGet feed. By default, TeamCity no longer adds all .nupkg artifacts to the project feed; instead, you can add the NuGet packages indexer build feature to build configurations whose artifacts should be indexed. If you prefer to have a single feed for the whole server, you can enable it at the Root project level and add the packages indexer build feature to build configurations which produce relevant packages. Alternatively, you can enable automatic packages indexing on the project NuGet Feed page. In this case, as it was before, all of the .nupkg artifacts produced by this project will be indexed automatically.

Docker Support

The Docker command runner with support for build, push, and some other docker commands has replaced the Docker Build runner
The Docker wrapper now supports .NET CLI and PowerShell runners, which means you can easily run these steps in a Docker container
The Docker wrapper can now use Gradle and Maven provided by the Docker images in the corresponding build steps
The Docker Compose supports multiple Docker Compose YAML file(s), space-separated paths to the docker-compose.yml files should be relative to the checkout directory.
AWS ECR (Elastic Container Registry) is now supported

Bundled Amazon S3 Artifact Storage

TeamCity now comes bundled with the Amazon S3 plugin, which allows uploading to, downloading, and removing artifacts from S3. Resolution of artifact dependencies, as well as clean-up of artifacts, is handled by the plugin. The artifacts located externally are displayed in the TeamCity web UI.

PowerShell Core support

Cross-platform PowerShell (PowerShell Core) is now supported on Windows, MacOS and Linux
Side-by-side installations of PowerShell Desktop and PowerShell Core are supported under Windows

Rerun build action improvements

Now when rerunning a build, TeamCity preserves all the custom parameters of this build and its dependencies as of the time of the original run.

Besides that, on the dependencies tab, there is now an additional option to rerun the failed/failed to start or cancelled dependencies of the build:

Shared Resources Improvements

You can view the resources used by the build on the Shared Resources tab of the Build Results page if at least one resource lock is defined in a build configuration. The tab displays the resources and their type, including the locks used by the build for each resource.
Shared resources can now be locked not only for regular builds, but for composite builds as well. A lock on the specified resource will be acquired when a composite build starts (when the first build of the composite build chain starts); the lock will be released when the composite build finishes (the last build in its chain is finished). The locks acquired on composite builds affect only these composite builds and are not propagated to their individual parts.

Other improvements

Browsing of artifacts inside archives is now supported for all external artifacts storages too (previously this feature was available only if artifacts were located in the internal artifacts storage).
Java 10 can now be used to run an agent, though Java 8 is still recommended.
Gerrit Commit Status Publisher now allows an admin to configure custom values for success and failure instead of +1 and -1 respectively. This label is also configurable. Note that since TeamCity 2018.1 Gerrit 2.6. is the minimal version supported by Commit Status Publisher.
The build chains page has got a new grouping option: it groups together in a single node all of the build configurations that are not related to the current context.
Duplicates finder (.NET) and Inspections (.NET) runners have been renamed to Duplicates finder (ReSharper) and Inspections (ReSharper) respectively. You can now select the platform bitness for InspectCode when using Inspections (ReSharper).
The bundled ReSharper CLT and dotCover have been updated to version 2018.1.2
The new option to copy build configurations build numbers has been added to the copy project dialog

Last modified: 20 April 2023