What's New in TeamCity 2022.04

Parallel tests on multiple agents

TeamCity can now split tests of a build in batches and run each batch on a separate build agent. This way, tests will run in parallel and the build will finish faster. The speed boost ratio depends on the number of test classes in the build and the number of agents used.

Refer to this article for details.

Advanced code quality inspections with Qodana

The Qodana plugin has been bundled with TeamCity. Now you can enable the Qodana build runner and add static analysis to your build chain, run advanced code inspections, find code duplicates, track code quality progress of your code. For details about the build runner, refer to Qodana.

If you previously installed the non-bundled Qodana plugin and used DSL, please check our upgrade notes

Enhanced integration with Amazon Web Services

TeamCity 2022.04 adds new features to its cloud integrations.

Migration of build artifacts from the local storage to Amazon S3

Version 2022.04 allows you to not only store new build artifacts in Amazon S3, but also move existing artifacts from TeamCity’s local storage to Amazon S3. This is particularly useful for teams who are just starting their migration from a self-hosted setup to a cloud platform.

Transferring build artifacts via Amazon CloudFront

The speed of transferring build artifacts stored in Amazon S3 depends on the geographical distance between you and the region where the S3 bucket is located. To help you increase the artifacts' upload/download speed and reduce costs, TeamCity 2022.04 adds native support for Amazon CloudFront, a content delivery network that offers low latency and high transfer speeds.

Enabling its support for an S3 storage will allow TeamCity to transfer build artifacts through the nearest CloudFront server.

Requiring Build Approvals

Some procedures in the production environment may require approval of more than one person. TeamCity now allows requiring manual approval from a specified person or a group for a build to run. To prevent users from triggering a build accidentally and to have more control over deployments, resource consuming builds, or resource removing operations, configure the Build Approval feature for your build.

Limiting number of running builds per branch

TeamCity 2022.04 helps you improve the allocation of your build agents by limiting the number of simultaneously running builds per branch. For example, your main branch may have an unlimited number of builds that will occupy as many build agents as they need, while you limit your feature branches to running just one build at a time.

Smarter VCS Integrations

TeamCity improves VCS integrations and provides the following new features.

Space merge requests

TeamCity integration with JetBrains Space now includes the Pull Requests build feature. If you enable this feature in a build configuration, TeamCity will automatically detect changes in merge requests submitted to your Space repository. For a build run on these changes, it will display the merge request details in the build's overview and send the build statuses back to JetBrains Space.

To enable this functionality in TeamCity:

In the project settings, configure a connection to JetBrains Space and create a Git VCS root with your Space repository URL and an empty branch specification.
In the build configuration settings, add the Pull Requests build feature with the JetBrains Space VCS hosting type:

You can specify the branch filter to monitor merge requests only on target branches that match the specified criteria. For example, if you set the +:refs/heads/feature-* filter, TeamCity will monitor merge requests sent only to branches whose names start with feature-.
To allow publishing build statuses to the commit details in JetBrains Space, you also need to add the Commit Status Publisher feature to this build configuration.

After the integration is configured, TeamCity will detect merge requests submitted to the JetBrains Space target branches. For builds run on the requested changes, it will display the merge request details in the Overview tab:

TeamCity will also send statuses per build change to timelines of merge requests in JetBrains Space (and to details of commits, if the Commit Status Publisher feature is enabled in the build configuration):

JetBrains Space - Merge Request Timeline

To protect a target branch and ensure that only verified requests are merged into it, you can set up Quality Gates for your Space repository and use a TeamCity build as an external check. If a build on a merge request fails, Space will notify you that the changes have not passed the required quality check.

Integration with GitLab issues

Starting from this version, TeamCity supports GitLab issues out of the box.

Queued builds reporting

Now the Commit Status Publisher updates the commit status in the version control system immediately after adding the corresponding build to the queue, providing you with the most up-to-date information. GitHub, GitLab, Space, Bitbucket, and Azure DevOps are all supported.

Running a custom build with a specific revision

When running a custom build, you can now specify an exact revision that may not necessarily belong to the list of changes known by the build configuration. This gives you a lot more flexibility when you want to reproduce historical builds, deploy older versions, debug new build configurations, and so on.

Security

Log4J and Log4Shell

Although TeamCity has not been affected by the Log4Shell vulnerability (CVE-2021-44228), some security scanners wrongly reported it as vulnerable. To avoid false-positive scanner reports, we have upgraded Log4J to the latest version.

Spring and Spring4Shell

Similarly to Log4Shell, the Spring4Shell vulnerability (CVE-2022-22965) does not affect TeamCity. However, to avoid false-positive reports from security scanners, we have upgraded the Spring Framework used in TeamCity to the latest version.

Native Git for VCS-related operations on the server

TeamCity can now use native Git as the default option for Git operations on the server. Switching to native Git improves the performance of the checking for changes operations on the server in comparison with the previously used JGit implementation. It also fixes a number of issues related to large Git repositories.

Before switching, make sure a native Git client version 2.29 or later is installed on your server machine, and the path to its executable is specified in the PATH environment variable. Alternatively, you can set the full path to the executable via the teamcity.server.git.executable.path internal property (no server restart is required). On Windows, remember to use double backslashes in the path.

To switch your TeamCity server to native Git, go to Administration | Diagnostics and open the Git tab. Here you can test the connection via native Git in any VCS root on your server. If you choose to test all VCS roots, TeamCity will check whether they successfully connect via JGit and then test their connection via native Git. This measure helps ensure that none of your pipelines will break after switching to native Git. If the connection test is successful, you can enable the native Git support on your server(s).

Our internal TeamCity server statistics show that using native git significantly improves the performance of the VCS-related operations on the server: new changes and branches appear several times faster in comparison with JGit.

New UI

Editing agent pools

It is now possible to edit agent pools and quickly assign agents and projects to them right in the new Sakura UI — without switching to the classic UI mode. To edit an agent pool, click Assign agents in its settings. In this dialog, you can choose what agents you want to assign to the pool:

Changes page

The new Changes page comes with filters providing flexible search options allowing you to sort changes by comment (commit message), by path to the changed file, and by revision number.

Storing Docker images produced by build in a public ECR registry

TeamCity can now store Docker images produced by a build to both private and — since this update — public ECR registries.

To be able to use this functionality, you need to add an Amazon ECR connection in Project Settings and choose the ECR Public registry type:

Remember to also enable Docker Support in your builds.

Automatic import of user avatars from external systems

When a user signs in to TeamCity via a third-party account, like GitHub or Bitbucket, for the first time, TeamCity will automatically fetch their avatar from the external system and attach it to their TeamCity user profile. Note that TeamCity will only be able to access avatars of users with verified emails (if you are using GitLab, check that a public email is set in your account).

It is possible to upload a different avatar in the TeamCity user profile settings afterwards.

Applying actions to multiple builds

It is now possible to select multiple builds and apply actions to all of them at once:

Pin/unpin
Tag
Compare with another build
Add a comment
Add to favorites
Remove

On the Overview tab of Build Configuration Home, you can select the required builds with checkboxes that appear when hovering over builds. To apply an action to them, use the respective command of the pop-up context menu. If you need to select a range of builds, press Shift and click build checkboxes at the edges of the range to be selected.

Perforce integration: Automatic creation of Helix Swarm test runs and status synchronization with builds

Commit Status Publisher has a new option for sending build status reports to Perforce Helix Swarm — Create Swarm Test. If you enable it, TeamCity will create a test run on the Helix Swarm server and update its status according to the build status in TeamCity.

Kotlin DSL API without version in package names

Kotlin DSL code generated by previous TeamCity versions had imports with v2019_2 in the package names, for instance:

import jetbrains.buildServer.configs.kotlin.v2019_2.projectFeatures.*

Since TeamCity 2019.2, there were no new DSL API packages as there were no major incompatible changes in DSL API. But the presence of several versions of packages causes constant troubles with code completion in IntelliJ IDEA, when it suggests several similar classes from packages with different versions.

To fix the issue with code completion, a new version of DSL API Maven artifacts is introduced in TeamCity 2022.04. These DSL API artifacts do not have a version in their package names. The newly generated Kotlin DSL code is switched to these unversioned artifacts automatically. The existing Kotlin DSL projects can be switched manually.

Getting the public part of project's SSH keys via the UI

You can now copy the public part of an uploaded non-encrypted SSH key from the project settings. To do this, go to Project Settings | SSH keys and click Copy the public key under the key name.

This way, project admins no longer need to ask the system administrator for a public SSH key whenever they need it (for example, to integrate their TeamCity projects with a VCS hosting service) — they can just get it via the TeamCity UI.

Other updates

Queued builds optimization improvements Before TeamCity 2022.04 a build in the queue could be optimized to an already started or finished build only. For instance if there are two build chains in the queue: A -> B and A -> C then the queued build A in both build chains could be replaced by the build queue optimizer only if there was another running or finished build A which has the same settings and revisions.
Starting with TeamCity 2022.04 this algorithm was improved to allow reusing builds which are still in the queue. So for the example above both build chains will be merged together while they are still in the queue, so both of the build chains will use the same queued build A.
Build failure conditions: Creating a build problem per each matching error
When configuring a Fail build on specific text in build log failure condition, you can now specify whether to create a build problem only for the first text occurrence found in a build log (default) or for each error that matches the specified pattern.
The Eclipse plugin has been unbundled from TeamCity. Contact our support if you need the plugin.

Fixed issues

See TeamCity 2022.04 release notes

Upgrade notes

Before upgrading, we highly recommend reading about important changes in version 2022.04 compared to 2021.2.x.

Previous releases

Roadmap

See the TeamCity roadmap to learn about future updates.

Last modified: 04 April 2024