TeamCity 2021.1 RC is here

The Release Candidate build for TeamCity 2021.1 is here!

This RC is the final stage of TeamCity Early Access Program 2021.1. While we are polishing the new features for the upcoming release, you can already try them in the Early Access mode. Here are the most prominent updates:

Customize automatically triggered builds

Build triggers now support custom parameters. This feature has been highly anticipated by our users, as it makes automatically triggered builds as versatile as builds started in the custom run mode.

In a build trigger’s settings, you can find the new Build Customization tab. Similarly to the Run Custom Build dialog, it lets you override values of build parameters and define if the checkout directory should be cleaned before the build:

Here, you can customize the value of any parameter used in this build configuration. Or, you can add a new parameter, and it will be available only in builds started by this trigger. If the current build has snapshot dependencies on other builds, such a parameter can also be used to override a certain property of a dependency build configuration: use the reverse.dep.<dependencyBuildID>.<property> syntax for this.

There are limitless combinations of how you can use this new instrument to autorun different builds within the same configuration. For example, the same script can autodeploy a project to different targets, depending on the triggered build’s preconditions like a source branch or launch time.  

This feature becomes even more effective if you combine it with our build step execution conditions. You can configure certain build steps to be executed only when special conditions are met, and then add multiple triggers each of whom will run a build with a slightly different set of steps. A popular use case is to run a limited number of tests in regular builds but a full set of tests in a nightly build, when the server load is the lowest.

Tip: TeamCity allows solving similar tasks in multiple ways, and in some cases, it is still preferable to create different build configurations. For example, if there are too many custom runs in the same configuration, it might be harder for TeamCity to predict the exact duration of each build. If you need to trigger builds with numerous different parameters, we suggest that you create a build configuration template and use it as a blueprint for several configurations, each with its own parameters.

Clean up stream workspaces on Perforce server

To optimally collect and process changes in Perforce streams used as feature branches, TeamCity needs to create and maintain dedicated workspaces on the Perforce server. Over time, these workspaces might consume a significant amount of resources on the Perforce server’s machine. Besides, if you want to close a task stream, you won’t be able to do this if there is a workspace associated with it. Both of these problems can be solved by deleting no longer necessary workspaces. Previously, there were no means to clean them up automatically, and any manual cleaning would require involving a Perforce server administrator. With the new Perforce Administrator Access connection, project developers can do this right from the TeamCity UI.

To set it up, go to your project settings in TeamCity and, under Connections, add a new connection with this type:

Enter the host and user credentials for accessing the Perforce server (the user must have the admin permission), and TeamCity will connect to it.

During every clean-up, TeamCity will detect and delete workspaces that have been inactive for more than 7 days. You can also delete them anytime by clicking Delete workspaces in the connection settings. Note that workspaces are deleted only on the server — not on build agents — and only if they were created by TeamCity.

It is also possible to delete workspaces associated with a specific stream. If a build configuration uses a VCS root with the enabled feature branch support, go to Build Configuration Home, open the Actions menu, and click Delete Perforce stream workspaces. By default, this action is available to all users with the Project Developer role.

In this menu, you can specify a path to a stream, and TeamCity will delete the related workspaces on the Perforce server.

Experimental UI: Show tests in tree mode in Build Overview

Test results are often the most important information you seek when opening the build details. We keep improving how tests are represented in our Sakura UI: our goal is to reproduce all instruments available in the classic UI and make them even handier for you. And now, Sakura UI supports the test tree view in the Build Overview.

In the Tests block, click Show grouped tests, and TeamCity will represent them in a tree mode, grouped together by project → build configuration → test suite → test package → test class. You can switch between the tree and flat structure anytime, depending on your current tasks.

As tests within the same group have a similar purpose, you might want to select them all at once or temporarily collapse them to focus on other groups — with the tree mode, this can be done with ease and is especially helpful if there are many tests in your build configuration. When a group is selected, you can apply actions like Investigate or Mute to it, like to a single test.

If you prefer a keyboard navigation, use Up and Down keys to navigate around the tree and Space to collapse or expand the selected group or test.

Other changes

• Since this RC, TeamCity will check if every new plugin, installed from the JetBrains Marketplace, is signed with a valid certificate. This will ensure that the installed plugin is safe to use and its source code is intact.
• The build status icon, available via the default http://<TeamCity Server host>:<port>/app/rest/builds/<buildLocator>/statusIcon REST API endpoint, is now provided in the SVG format instead of PNG. The statusIcon.svg endpoint is still supported for compatibility with existing scripts.
• The useMirrors parameter in the Kotlin DSL of Git VCS roots is deprecated and replaced by the checkoutPolicy parameter that supports the following values: AUTO (default), USE_MIRRORS, NO_MIRRORS, SHALLOW_CLONE. Read more about these checkout policies here.
• Now it is possible to choose if you want to preserve the system directory when upgrading or reinstalling a TeamCity agent on Windows. Preserving it will help reduce the duration of the first build after the upgrade/reinstall, as the agent won’t need to perform a clean checkout.
• Bundled Amazon Corretto Java has been updated to version 11.0.11.9.1 in the TeamCity server Docker images and Windows installers.
• Bundled dotCover and ReSharper CLT have been updated to version 2021.1.2.
• Bundled JaCoCo has been updated to version 0.8.6.
• Bundled Kotlin compiler, used in TeamCity DSL, has been updated to version 1.4.32.
• Bundled Kotlin, used in the Kotlin Script build runner, has been updated to version 1.5.0.
• JDBC drivers for external databases have been updated to the following versions:
  • MySQL — 8.0.24
  • MSSQL — 9.2.1
  • PostgreSQL — 42.2.20

---

See all resolved issues.

---

Stay tuned for the upcoming updates and check our roadmap for details.

Download TeamCity Morena 2021.1 RC or pull the Docker image with the EAP tag. Remember to install it on a trial server as the new version changes the TeamCity data format and downgrading to the previous production version is not supported.

All our EAP releases come with a 60-day Enterprise evaluation license for an unlimited number of agents and build configurations.

You are welcome to share your feedback in our forum or issue tracker.

Happy building!