TeamCity 2024.03 Is Here
In TeamCity 2024.03, we’re introducing some highly upvoted features, including optional artifact dependency, bundled HashiCorp Vault plugin, and supporting configuration cache for the Gradle build runner. Read on to learn what’s new.
Semi-automatic security updates
To keep you ahead of the curve in preventing and mitigating security issues, TeamCity 2024.03 now automatically downloads critical security updates. This approach helps to keep your system fortified against emerging risks and to swiftly tackle major vulnerabilities. Note that after an update is downloaded automatically, a system administrator still needs to approve its installation.
Bundled deal: the HashiCorp Vault plugin is now part of TeamCity
TeamCity has enjoyed integration with HashiCorp Vault via a plugin for a while now. Last year, we revamped the way this integration works, making it much easier to configure.
Now, starting from version 2024.03, we’re bundling the plugin with TeamCity, making it an integral component of any TeamCity installation.
Head over to our documentation to learn more about TeamCity’s HashiCorp Vault integration.
Optional artifact dependency
Artifact dependencies enable your build configurations to retrieve files generated by other configurations or other builds in the same build configuration. To establish these dependencies, you have to define artifact rules outlining which files to download and their designated storage locations.
Previously, if TeamCity was unable to locate files matching these rules, a build would fail with the “Unable to resolve artifact dependency” error.
Starting from version 2024.03, we’re introducing a more flexible approach to defining artifact dependencies. Now, you can configure the dependency to be ignored in the following cases:
- The source build does not exist at all (this problem won’t be ignored if there are other, non-optional rules).
- The source build does not have the required file.
- The artifact rule is based on an archive and archive does not contain a required file.
If you’d like to share some feedback on the feature, please feel free to do so in this YouTrack ticket.
Trust but verify with untrusted builds
The Pull Requests feature allows you to review new code before adding it to the main codebase. You can choose to run builds from any contributors or only from those within your organization. The first option poses certain security risks, as it might expose your TeamCity server to harmful code. Meanwhile, the second choice restricts collaboration with a broader base of contributors.
Starting from version 2024.03, we’ve eliminated this trade-off between collaboration and security by introducing a new feature called the untrusted builds group. With untrusted builds, TeamCity can now differentiate between changes authored by trusted users and changes coming from an external source.
With this new functionality, you can specify the conditions that determine how pull requests coming from external sources should be handled. You can also specify the list of approvers who will receive a notification in case such an untrusted build is queued.
The untrusted builds group currently supports GitHub and GitLab. Learn more about Untrusted builds in our documentation.
dotCover runner
JetBrains dotCover has been supported as a coverage tool for .NET-related projects in TeamCity for a while now. In version 2024.03, we’ve introduced a new build runner in the .NET Support plugin that integrates with the dotCover tool.
The new dotCover runner allows users to:
- Run an arbitrary process under dotCover code coverage profiling to produce a coverage snapshot.
- Merge snapshots between build steps produced by other .NET or dotCover runners.
- Generate merged reports across a build chain for parallel tests and transform them into TeamCity’s custom reports.
The new functionality is useful for profiling arbitrary processes running .NET applications and combining reports between builds into one build chain.
Learn more about our dotCover support in TeamCity in our documentation.
.NET test retry in TeamCity
In version 2024.03, we’ve introduced an exciting new feature for the .NET build runner that provides the possibility of setting up retry policies for tests that failed in the same build. This feature will help address test flakiness and mitigate transient failures when running integration tests.
If you’d like to share feedback on the feature, please feel free to do so in this YouTrack ticket.
Configuration cache support in the Gradle runner
Gradle’s configuration cache option significantly improves build performance by caching the result of the configuration phase and reusing this for subsequent builds. This allows Gradle to skip the configuration phase entirely in subsequent builds if there are no changes affecting the build configuration, such as modifications to build scripts.
Before version 2024.03, configuration cache support was not available in TeamCity’s Gradle build runner. With this release, we’re adding this functionality to TeamCity, enhancing the efficiency and performance of Gradle builds. Head over to our documentation to learn more about how to enable the configuration cache option for your TeamCity setup.
Git the ball rolling: enhanced Git submodule and large file storage (LFS) support
A Git submodule is a repository embedded within another Git repository. It allows you to include and track an external repository as a subdirectory within your main project. This is useful when you want to incorporate external code or libraries into your project while keeping them in a separate repository with its own version control history.
Previously, in cases when the project and its submodules had different VCS roots, it was impossible to configure submodule authentication that was different from the main repository one. For LFS, you had to use the same credentials as used for the Git VCS root itself.
Starting from 2024.03, we’re introducing a new option that provides support for external submodules as well as external LFS in TeamCity. Now, you have the ability to incorporate parameter-based credentials into your TeamCity projects.
As you check out source files, TeamCity seamlessly employs these credentials to access and retrieve the necessary files. Upgrade your project security and efficiency with this latest enhancement.
We look forward to receiving your feedback on the feature in this YouTrack ticket.
More control over Helix Swarm review comments
Previously, the Commit Status Publisher for Helix Swarm would comment on a review for every stage of the build (queued, started, succeeded/failed), causing potential spam issues, particularly with multiple tests running on a review.
Now, the Commit Status Publisher will only publish code review comments for the final “build finished” event. The possible comments are either: “Build was successful” or “Build failed“.
In addition to that, users will have the option to enable or disable the posting of code review comments via a checkbox in the build feature settings. This setting will also be available in Versioned Settings | Kotlin DSL for greater flexibility and control.
New parameter dialog
In the 2024.03 version, we’ve revamped the Add/Edit Parameter dialog, which you use when setting up build parameters in TeamCity.
In the updated dialog window, you can now opt for a new parameter type – Remote secret. You can select this type for parameters requiring values fetched from a remote source, such as HashiCorp Vault. This new parameter type also makes it easier for you to develop your own plugins.
For more information about the 2024.03 features, please visit our documentation. In case you have any questions, don’t hesitate to reach out.
Happy building!
Subscribe to TeamCity Blog updates
