Early Access Program

TeamCity 2021.1 EAP3 is here

The third build of TeamCity 2021.1 Early Access Program is available for download.

TeamCity 2021.1 EAP3 brings more than 70 improvements and fixes. In these release notes, we describe the most exciting updates.

TeamCity 2021.1 EAP3

Node.js build runner

To improve your experience with building JavaScript projects in TeamCity, we now provide a dedicated build runner for Node.js with support for npm and yarn commands. If your repository contains a package.json file, TeamCity will automatically detect used frameworks and propose adding respective build steps. For example, an npm ci step to install necessary dependencies or npm test to run Mocha tests and properly report their results in the TeamCity UI. You can then manually adjust these steps as you like.

Currently, all Node.js steps can only be run inside a Docker container, which means that the only prerequisite of this runner is to have Docker installed on build agents. TeamCity uses the node:lts container by default.

Node.js runner

If you prefer configuring steps as code, here is an example syntax for Node.js:

nodeJS {
    shellScript = """
        npm install mocha-teamcity-reporter --no-save
        npm run test -- --reporter mocha-teamcity-reporter
    dockerImagePlatform = NodeJSBuildStep.ImagePlatform.Windows
    dockerPull = true

Learn how to allow this runner to access private NPM registries in our EAP documentation.

New search mode based on Elastic

TeamCity lets you search builds by their numbers, tags, and many other parameters. Previously, it could use only a local search index, stored next to the server itself. Since this EAP, it provides an alternative search mode based on Elastic. This mode allows storing a global search index on your Elastic host, which is most optimal for TeamCity multinode installations.

With the local search mode, each node spends its disk space and resources on storing and maintaining the search index. With the new mode, there is a single index for all nodes, which significantly offloads their indexing operations and saves their disk space.

You can switch to this mode on the Root project level in Project Settings | Search. To connect to your Elastic host or cluster, enter its URL and credentials. You can also set a custom name for a TeamCity index.

After you save the new settings, TeamCity will spend some time reindexing builds. The exact duration depends on the size of your server. You can track or control the progress in the Diagnostics table.

Elastic-based search

Note that in terms of EAP, results provided by the Elastic search can differ from those of the local search. Search by build log is currently supported only for the local index, but we plan to support it in the Elastic search as well.

Read-only project settings

Versioned project settings is one of the most popular features of TeamCity. Based on your feedback, we keep adding more controls to this functionality.

By default, if you enable synchronization of a project’s settings with a repository, all changes made in the TeamCity UI will be automatically reflected in the repository, and vice versa. But in some cases, it might be convenient to prohibit editing project settings via the UI.
For example, if you import settings from a read-only default branch and then change these settings in the UI, TeamCity will fail to commit back to the repository, and builds of this project won’t be able to start. Or, if you store a TeamCity project specs next to its source code, you might want to track and approve all changes solely by the means of VCS.

To cover these and any similar cases, we’ve introduced a new option: Allow editing project settings via UI. It is enabled by default, which corresponds to the regular behavior. If you disable it in a project, this will make the project’s settings read-only in the UI and prevent TeamCity commits to the settings’ repository.

To see the new option, go to Project Settings | Versioned Settings | Configuration:

Read-only project

Read more about this feature in the EAP documentation.

Allow multiple VCS triggers per build configuration

Now, you can add more than one VCS trigger to a build configuration. This is convenient if you want to trigger builds in the same configuration but according to different rules and with different branch filters. This allows you to set a quiet period for builds in all branches except one where a build will start as soon a new change is committed. Or, you can configure a trigger to start builds on each check-in only in one given branch.

In the next EAP update, we want to make VCS triggers even more flexible and support custom build parameters right in their settings.

Support ChangeView specification for Perforce VCS roots

If a Perforce VCS root is set to the Client mapping mode, TeamCity will automatically map the root’s depot to each specific build agent machine. Since this EAP, this mode supports the ChangeView specification field which lets you limit the root’s scope to a particular revision or multiple revisions.

To use this option, open the settings of a Perforce VCS root, choose the Client mapping connection mode, and enter the client mapping. For example:

//my-depot/... //team-city-agent/...

where 90 is the number of the exact revision of dir1 and automaticLabelWithRevision is the labeled revision of dir2. All the other revisions of these directories will not be monitored by this VCS root.

In addition to this, TeamCity now supports the ChangeView specification in Perforce clients and understands the @revision syntax in the import statements of Perforce streams’ definitions.

Restrict permission to customize builds with personal patches

TeamCity allows running a custom build with your local changes without affecting the project’s source code in a VCS. To run such a build, you need to send the patch with changes to the TeamCity server: either by using our Remote Run functionality for IDEs or by uploading it via UI or REST API. As the patch resides on the build agent machine during the build, it would be wise to ensure that it includes only trusted changes and cannot potentially harm the next builds running on this agent.

For this purpose, we’ve created a new user permissionChange build source code with a custom patch. With this permission, you can now granulary control who can patch builds or, if necessary, fully restrict this functionality in important projects.
On upgrading to 2021.1 EAP3, it will be automatically enabled for the default Project Developer role and other roles with the Customize build permission.

Other changes

  • ReSharper Inspections and Duplicates Finder now support the cross-platform mode and can be run inside Docker.
  • Updates for Python:
    • The Python runner now supports the Poetry environment tool for packaging and managing dependencies.
    • Missing Python modules can be automatically installed on a build agent.
  • The default port in the TeamCity installer for Windows has been changed to 8111. Now, both tar.gz and exe installers use the same port.
  • Non-portable Kotlin DSL format is deprecated. It is no longer possible to create new projects in this format. For compatibility, projects that are already stored in this format will continue working.
  • TeamCity Lucene-based search now uses the OR operator by default instead of AND. This corresponds to the default Lucene syntax and helps optimize the search behavior and reduce its index size.
  • Linux Docker images of TeamCity agent and server now come with a Perforce client.
  • The bundled ReSharper and dotCover tools have been updated to version 2021.1.1.
  • Bundled Ant has been updated to version 1.10.10.
  • JGit version, used in the Git plugin, has been updated to
  • SVNKit, used in Subversion VCS roots, has been updated to version 1.10.3.

See all resolved issues.

More features are on their way — stay tuned and check our roadmap for details.

Download TeamCity Morena 2021.1 EAP3 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!

image description