TeamCity 2021.1: Kotlin and Node.js Build Runners, Trigger-Defined Parameters, High Availability, and more
TeamCity 2021.1 brings brand-new build runners for Kotlin and Node.js, improves integration with Perforce, and enables a whole range of new workflows by allowing build triggers which define parameters to be used inside build scripts. Users with demanding availability requirements will love the new option to transfer main server responsibilities to secondary nodes in the runtime with minimum downtime. There are also multiple updates to the Sakura UI that will make your work with TeamCity easier, faster, and more enjoyable.
Build. Test. Win.
Kotlin script build runner
Over the past several years, Kotlin has grown immensely. We have seen a lot of interest in using it not only to configure pipelines as code, but also to write build scripts. The new Kotlin script build runner is a great choice in a huge variety of scenarios. It is cross-platform, supports importing external libraries, and can be used in most places where you currently use the Command Line build runner.
Node.js build runner
Today, JavaScript is the most popular programming language in the world, and a lot of this is due to Node.js, the world’s leading JavaScript runtime. TeamCity 2021.1 comes with a new Node.js build runner that provides first class support for building your web applications. It supports npm and yarn, can work with public and private registries, and automatically detects build steps based on package.json. Just like with all other build runners in TeamCity, you can run your builds inside a Docker container and set them up using a Kotlin-based configuration.
Thread dumps for Docker-based builds
TeamCity has always allowed viewing thread dumps of processes running on build agents. However, when your build was run in Docker, this was difficult. Version 2021.1 lets you view thread dumps of Java processes running in Docker containers on any operating system. For Linux-based Docker containers, you can also see the list of other running commands and their parameters.
In addition to the new Kotlin and Node.js build runners and thread dump viewing improvements, the new version features improved ReSharper Inspections and Duplicates Finder build runners which are now cross-platform and can run in Docker.
May Perforce be with you
TeamCity has always been famous for its ability to scale to large projects with lots of big files, as well as for its top-notch integration with Perforce. Version 2021.1 brings the Perforce integration to the next level with a number of new great features:
- Improved commit hooks setup. Now you can set up commit hooks and have your builds automatically triggered by installing only one single script on the Perforce server.
- Perforce workspace cleanup. TeamCity now provides manual and automated clean-up of the Perforce workspaces created by the TeamCity server.
- ChangeView specification support. You can now limit the VCS root scope to particular revisions with the use of the ChangeView specifications. Usage of the @revision syntax in the import statements of Perforce stream definitions is now also supported.
Hardening the security of your CI
Special care is put into the TeamCity security features, and we keep improving them with every new release.
Greater security with improved access tokens
Version 2021.1 allows you to generate access tokens that are limited in time and scope. Now you can grant scripts that interact with the TeamCity API just enough rights to do their job, without the fear of giving them too much power. You also no longer have to remember to revoke their access after they finish.
Separate permission for personal builds with patches
TeamCity now has a separate permission for running personal builds with custom patches. This helps you ensure that all code executed on build agents is authored only by trusted users.
With great power comes great configurability
Trigger-defined parameters
TeamCity 2021.1 opens new dimensions of control over your build configurations. Your build triggers can now define custom parameters to enable or disable build steps, or change what happens inside your build scripts. For example, your nightly builds can now be different from the builds triggered by version control check-ins, all within the same build configuration.
Git shallow clones
Building on cloud agents just got faster. Starting with 2021.1, you can enable Git shallow cloning and check out the latest version of source code with depth=1, without creating local Git mirrors. This will be particularly useful for companies that spin up clean, short-lived build agents in the cloud for every build.
Multiple VCS triggers support
You are no longer limited to only one VCS trigger per build configuration – TeamCity now allows adding multiple triggers with different rules and with different branch filters. For example, your release branch can be built immediately after the commit, but all other branches will have to wait for their own VCS quiet period.
Disabling UI editing
In TeamCity, you can set up CI/CD pipelines through the UI, through Kotlin configurations, or through a mix of both. However, mixing different methods may lead to a lot of confusion and versioning problems. To ensure that your configurations stay predictable and easy to manage, we have added a new option that will allow administrators to prohibit editing project configurations through the UI if they are set up using Kotlin.
High availability taken even higher
For many large organizations, a highly-available CI is critical to their workflows. TeamCity 2021.1 strengthens multinode setups with three new features.
Switching main node responsibility in runtime
The larger your CI/CD setup is, the more important it is to regularly perform server maintenance tasks. At the same time, any server downtime directly translates into a lapse in your team’s productivity. To allow for high availability and minimize the downtime during maintenance, TeamCity 2021.1 introduces the new “Main TeamCity node” responsibility that can be transferred to a secondary node in runtime. When you do it, the secondary server becomes the main node and automatically receives all of the main node’s responsibilities, including processing builds and managing build agents.
Controlling the number of builds on secondary nodes
TeamCity now allows you to define the share of builds that will be processed by its nodes. This helps you make sure that every server takes just the right amount of the build processing load and doesn’t exceed its hardware capabilities.
Elastic-based search
Previously, every TeamCity node had its own search index that was stored locally. Version 2021.1 provides an alternative search engine based on Elasticsearch. It has a distributed index, consumes less disk space, and works more efficiently in multinode installations.
Faster. Higher. Stronger. More beautiful.
We are continuing to further improve the Sakura UI, making it faster, easier to use, and supporting all workflows from the classic UI. The new version brings a UI Assistant that shows new users how to navigate around the interface, improvements to the Build Status widget, updates to the Build Overview page, project hierarchy views, and more.
These are just a few of the many great new features in TeamCity 2021.1. For the full list of changes, please refer to the TeamCity documentation.
Subscribe to TeamCity Blog updates
