What's New in TeamCity 2021.2
Two-factor authentication
TeamCity now provides built-in two-factor user authentication (2FA). Enabling it on your TeamCity server grants it an extra level of security. Users will have to verify their identity in two steps: by providing their regular credentials plus by submitting disposable keys, generated on their personal devices.
2FA is set to Optional by default, but you can make it Disabled or Mandatory on your server — in Administration | Authentication. The optional mode allows users to decide whether they want to enable 2FA for their accounts or not. The mandatory mode prevents users from accessing TeamCity without the 2FA verification. After you enable it, users will get a grace period of 1 week during which they are supposed to set up 2FA for their accounts.
Read how to enable 2FA on your server and set it up for your user account.
C# Script Runner
The new C# Script runner offers a handy way to automate your service tasks in C#: prepare a build environment, create OS users, report to messengers, and so on. This runner is a good alternative to PowerShell and Kotlin for users who feel more confident with C#.
The runner can launch C# scripts across platforms: on Windows, Linux, and macOS. It needs .NET 6.0, so the easiest way is to launch it inside a Docker container with preinstalled .NET. It also requires installing our custom C# Interactive shell as an agent tool.
Another advantage of this runner is that it’s capable of automatically restoring NuGet packages referenced in your scripts. By default, TeamCity searches for packages on NuGet.org, but you can specify other target feeds, including private and TeamCity-internal ones.
To configure a C# Script build step, you just need to enter the script code (or a path to the .csx file) and its arguments, if necessary. Read about other settings in this article.
Perforce integration: run builds on shelved files, report statuses to Helix Swarm, and more
TeamCity 2021.2 brings plenty of enhancements for projects that rely on the Perforce Helix Core VCS.
Run builds on shelved files
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.
Reporting build statuses to Perforce Helix Swarm
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:
Automatic labels support
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.
Parameterized connection variables
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.
JetBrains Space integration: authenticating users and creating projects from repositories
Space is the new JetBrains collaboration solution for software teams. If your company is already on board with it, you can now:
Natively create projects, build configurations, and VCS roots from JetBrains Space repositories.
Allow users to sign in to TeamCity with their JetBrains Space accounts.
This integration requires preconfiguring a connection to your Space instance: see how to do this.
Create projects, build configurations, and VCS roots from JetBrains Space repositories
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.
Authenticate in TeamCity with JetBrains Space account
To activate the Space authentication on your server, you need to:
Configure the connection to Space on the Root project level.
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.
Authenticate in TeamCity with Azure DevOps Services account
If your team uses Azure DevOps Services, its members can now sign in to TeamCity with their Azure accounts.
To enable this functionality on your TeamCity server:
Configure an OAuth 2.0 connection to your Azure DevOps Services instance as described here.
Enable the Azure DevOps OAuth 2.0 module in Administration | Authentication. To secure the access further, you can restrict the scope of Azure organizations whose members can access TeamCity:
Now, users will be able to sign in to TeamCity by clicking the Azure icon on the login page and confirming the authentication.
User Interface improvements
Version 2021.2 brings the following TeamCity UI improvements:
Displaying user avatars.
Displaying pending changes and change details in experimental UI.
Ability to group builds by projects on the build chain graph in experimental UI.
Displaying user avatars
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.
Experimental UI for displaying changes
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 new UI also makes these pages more interactive. For example, when viewing pending commits, you can expand each test and build problem to see their details.
Pending Changes:
Single Change:
Group builds by projects in experimental build chain graph
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.
Other improvements
OpenSSH keys support
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.
Kotlin DSL updates
The typed Kotlin DSL is now supported for numerous settings of projects and build configurations. See the full list of improvements here.
Pause and resume build queue on secondary nodes
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.
See the full list of actions currently supported on secondary nodes.
Pass parameters to selected dependency builds
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.
Autodetecting PowerShell on ARM64
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.
Easier API access with cookies
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.
Easier CSP header customization
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.
Fixed issues
Upgrade notes
Before upgrading, we highly recommend reading about important changes in version 2021.2 compared to 2021.1.x.
Previous releases
Roadmap
See the TeamCity roadmap to learn about future updates.