Versions Compared

Key

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

Table of Contents

Warning

This page is currently under construction.

Read-Only Node

TeamCity makes a step towards High Availability by introducing a read-only mode for the server. It is currently 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 upgrade.
Since the Read-Only node uses the same Data Directory and the same external database as the main TeamCity Server, a prerequisite of using the Read-Only node is to ensure that it has access to the data directory and database of the main TeamCity Server. In addition to the data directory shared with the main server, the Read-Only node requires its own 'local' data directory where it stores some caches, unpacked external plugins and some other configuration.
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. Details are available in the dedicated documentation section.

User Interface Changes

We continue updating the interface:

  • the build line has been redesigned a bit and the agent history page now looks similar to the All Builds page introduced in 2017.2.x:


  • new build row presentation, featuring the artifacts icon, has been added to the overview and favorite builds pages
  • the build configuration home page has been redesigned (besides, internally it now uses the REST API to show its data)

pinte

Uploading SSL / HTTPS Certificates

TeamCity now allows uploading a custom trusted certificate, e.g. be a self-signed certificate, or a certificate signed by a not well-known certificate authority (CA). As this 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.

Previously, to allow such connections, the certificate had to be imported into Java used by the TeamCity server with help of the keytool utility. Now it can be easily uploaded to the server using the TeamCity Web UI: just go to to the Root project administration area and select SSL / HTTPS Certificates menu item in the sidebar. This will automatically distribute the uploaded certificate to all agents. It is also possible to manually add certificates to required agents only. 

Server independent / portable Kotlin DSL format

The upcoming 2018.1 version of TeamCity will support a much simpler format of Kotlin DSL settings allowing sharing the same Kotlin DSL scripts between different servers and even reusing the same Kotlin DSL script by several projects on the same server.

A new setting (enabled by default) produces the simplified version of Kotlin DSL and 

  • 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 using the checkbox "" (checked by default when the Kotlin format is selected):

Compare the old and new definition of a build configuration:

Code Block
titleOld format
object MyBuildType : BuildType({
    uuid = "<some uuid>"
    id = "MyBuildType"
    name = "My build configuration"
 ...
});
Code Block
titleSimplified 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:

Code Block
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!'""""
        }
    }
})
Note

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:

Code Block
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.

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, everything related to the current project looks like this:

Code Block
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:

Code Block
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 with some project sources in a public VCS repository and then share the link to this repository, so that others could easily restore these settings on their own servers.

Inherited build steps configuration improvements

Ability to redefine inherited build step settings

In the current TeamCity version, if a build step is defined in a template, it is shown as read-only in a build configuration inheriting this build step. If some customization is required, then a parameter reference has to be defined for some settings in the template, and a specific value should be set for this parameter in the build configuration. However, this workaround works for text fields only.

It is finally possible to customize an inherited build step, i.e. it is possible to change every setting of the inherited build step without the need to introduce parameters.

hidden-data
Note that the redefined build step preserves its place in the steps order. 
Note that overriding any property in an inherited BC will fix all the other values in the resulting build config, and changing other properties of the same feature in a template will not take affect. It concerns build steps, triggers, build features, artifact deps, agent reqs, failure conditions.
 

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 from 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. 

Enforced settings

Starting with this version, TeamCity provides the ability to enforce settings for all of the build configurations in a project hierarchy. For instance, with 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 system administrator can associate a project with a specific enforced settings template - project administrator permissions are not suffieicient. 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 the higher priority.

Currently build features, options and parameters can be enforced.

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 can lead to a really large feed, delays with packages appearance, increased disk usage for the feed metadata and sometimes terrible 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

  • 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 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

Re-run build action improvements

Now when re-running 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 stored in the internal artifacts storage).
  • Java 10 can now be used to run an agent.

  • 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.

  • Build chains page has got new grouping option: it groups together in a single node all of the build configurations which 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