What's New in TeamCity 2021.2

Perforce allows users to temporarily share changed files with each other without checking them into depots. This is called shelving. And now TeamCity can run builds on such shelved files, which lets you pretest the local code in a real build environment.

You can run a build on a shelved changelist:

• Manually: via a custom run, or

• Automatically: by configuring a Perforce shelve trigger.

In both cases, TeamCity will run a personal build which is a build type intended for processing changes that don’t affect the project version history.

These options are available for all build configurations that use Perforce VCS roots.

Learn more.

If a build is run on a shelved changelist, TeamCity can automatically report its status to Perforce Helix Swarm. If you use this tool for code reviews, there is no more need to go back and forth to TeamCity just to check if the build succeeded or not.

To set up this integration, enable the Commit Status Publisher feature in a build configuration that uses a Perforce VCS root:

After this feature is configured, TeamCity will be publishing the build statuses’ updates as comments to the respective code reviews in Helix Swarm:

Learn more.

TeamCity can assign custom labels to your project sources. In case with Perforce, the VCS labeling build feature was previously creating static labels, which are archives of local workspaces. However, it seems that automatic Perforce labels are way better in terms of performance, as they work as mere aliases for changelists. And since version 2021.2, TeamCity publishes automatic labels by default.

If you prefer using static labels, please read our upgrade notes with an instruction on how to revert this change on your server.

Learn more.

If a build agent needs to connect to several Perforce VCS roots during one build run, it can now get connection parameters of each of these roots.

Previously, if you wanted to use P4PORT, P4USER, or P4CLIENT in your build scripts, you could only refer to variables of the first Perforce root. Now, TeamCity stores these variables as parameters, so you can reference them in the scripts separately for each root: P4USER, P4PORT, P4CLIENT. For example, env.P4PORT=%vcsRoot.<rootID>.port%.

where rootID is the VCS root’s external ID, specified in its settings.

Learn more.

After the connection is configured, the JetBrains Space button will become available in the project and build configuration creation wizards in TeamCity. When clicking it for the first time, you will need to sign in to Space and grant TeamCity access to view your project data.

TeamCity will display the list of Space repositories available to you:

Choose a repository to create a project or build configuration from — and TeamCity will scan it and suggest the settings, as described here.

tip

You can similarly add additional JetBrains Space roots to an existing project.

To activate the Space authentication on your server, you need to:

1. Configure the connection to Space on the Root project level.

2. Enable the JetBrains Space authentication module in Administration | Authentication.

As a result, users will see the JetBrains Space icon on the TeamCity login page and can click it to sign in with their Space account.

tip

If you want to associate an existing TeamCity user with a JetBrains Space user, you can do this in the authentication settings of their TeamCity profile.

User avatars are now displayed next to the usernames, both in the classic and experimental UIs. Visual icons can help quickly identify the commits’ authors.

You can upload the avatar in your user profile settings.

The Pending Changes tab and single Change page have been fully reproduced in the new UI. They have a familiar layout of the classic pages, but offer a better look&feel.

The Pending Changes page displays the list of changes committed to the remote repository since the last successful build.

The individual Change page allows you to view detailed information about each change and displays the list of failed tests and build problems that emerged when this change was introduced.

It is now possible to group builds by projects on the experimental build chain graph. This can give a convenient overview of a large pipeline.

To try this option, open the results of any build that is a part of a chain, go to its Dependencies tab, and switch to the Chain mode.

TeamCity now supports keys in the OpenSSH format, including ECDSA and ED25519. You can upload such a key to TeamCity and reuse it when configuring VCS roots or running an SSH agent during a build.

The support for this format has also been introduced in a bugfix build TeamCity 2021.1.4.

The typed Kotlin DSL is now supported for numerous settings of projects and build configurations. See the full list of improvements here.

In a multinode setup, a secondary node has limited functionality compared to the main one, but we strive to eventually make it equally functional. This release makes it possible to pause and resume the build queue on secondary nodes.

TeamCity allows passing build parameters up the chain: that is, a later build in a chain can override properties of a preceding build. This lets you compose flexible and adaptable pipelines. To improve the flexibility even further, we’ve extended the reversed parameters’ syntax to support build ID masks.

Previously, it was possible to redefine a property only in a specific build or in all preceding builds at once. Now, you can specify a set of target builds if their IDs have a common prefix or suffix:

reverse.dep.[prefix]*[suffix].<property_name>

where prefix corresponds to the beginning of the target builds’ IDs, and suffix corresponds to their ending.

Read more about this syntax.

TeamCity now can automatically detect PowerShell in ARM64 systems by checking the recommended locations: ~/powershell and /opt/microsoft/powershell/<version>/. To add a custom location to this scope, you can set a special agent property, as described here.

Disabling cookies is not anymore necessary for accessing TeamCity from external HTTP clients.
Previously, if you needed to send an API request with enabled cookies, it was required to pass both an access token and CSRF token. Now, sending an access token for authentication will be enough.

To customize a Content Security Policy (CSP) header, which prohibits downloading unknown external resources from TeamCity, it is now enough to provide only the custom part, with no need to specify the full header value. If the full value is provided, only the different parts will be applied.