What's New in TeamCity 2022.04
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.
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
TeamCity 2022.04 adds new features to its cloud integrations.
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.
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.
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.
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.
TeamCity improves VCS integrations and provides the following new features.
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 withfeature-.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):
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.
Starting from this version, TeamCity supports GitLab issues out of the box.
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.
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.
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.
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.
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.
tip
We keep reproducing the classic TeamCity features in its experimental UI, and a majority of them have already received a new implementation. If you haven't tried the new UI for a while or at all, we encourage you to give it a try this time. Our goal is to make the experimental UI not only as functional as the classic one but a lot more responsive and enhanced with easier navigation and widgets.
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:
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.
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 Registry Connections in your builds.
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.
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 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.
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.
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 -> BandA -> Cthen the queued buildAin both build chains could be replaced by the build queue optimizer only if there was another running or finished buildAwhich 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.
Before upgrading, we highly recommend reading about important changes in version 2022.04 compared to 2021.2.x.
See the TeamCity roadmap to learn about future updates.