TeamCity 2020.2 Help

What's New in TeamCity 2020.2

New header

TeamCity 2020.2 comes with a more modern header in both classic and experimental UI.

New header 2020.2

Python support out of the box

TeamCity 2020.2 comes with a new bundled Python runner. It automatically detects Python on build agents and allows running Python scripts on all supported platforms.

Comparing to the now obsolete Python Runner plugin, the new runner tightly integrates with TeamCity and introduces extra possibilities, such as:

  • Automatic test reports (via unittest and pytest) and inspections (via flake8 and pylint)

  • Using virtual environments

  • Launching a build step inside a Docker container

Bundled Python build runner

If you were using the old plugin to run your Python projects, we highly recommend switching the respective build steps to the bundled runner. As the new runner offers extra settings, these steps have to be reconfigured manually.

Read how to configure the new runner.

Agentless build steps

Since this release, last steps of a build can finish without a build agent, in an external software.

Normally, a running build occupies a build agent until all its steps finish. In some cases, a build needs to wait for a process executed by some external system, outside of the build agent. For example, when the last step is responsible for deploying via a third-party software, an agent would simply do nothing until this step finishes.

Now, a build can be detached from its current agent. This agent becomes available to other builds, while the build continues running in the "agentless" mode.

To detach an agent, a build should send the ##teamcity[detachedFromAgent] service message.
There are dedicated REST API endpoints which can be used to report the progress of the agentless build and end it once the external process finishes. You can read more about them in the documentation.

There is a limit for a number of agentless builds running simultaneously. It is equal to the maximum number of authorized agents in your installation. This way, if you have 10 agent licenses, you can run in parallel up to 10 agents plus up to 10 agentless builds.
If the limit is exceeded, a build won't be able to detach from its agent until some of the running agentless builds finish.

Authentication with GitHub.com, GitHub Enterprise, GitLab.com, GitLab CE/EE, Bitbucket Cloud

Now, users can authenticate in TeamCity with their external accounts in:

This integration requires creating a dedicated application on the VCS hosting provider's side and a connection in TeamCity. You can find detailed instructions on how to configure a connection here.
To enable authentication with each of the listed providers, a system administrator needs to activate a respective authentication module. If any of these modules is enabled on your server, users will see its icon above the login form:

Authentication with VCS hosting provider

To sign in as an external user, you need to click this icon and, after the redirect, approve the TeamCity application in your external account. If successful, you will be signed in back to TeamCity.
If a user with your external account's email is registered in TeamCity, you will be authenticated as this user. Otherwise, TeamCity will create a new user profile (unless this option is manually disabled).
To be automatically recognized by TeamCity, users can also connect their profiles to external accounts in My Settings & Tools.

Admins can map TeamCity users with external accounts and limit providers' groups/organizations/workspaces whose members can access the server.

Learn how to enable and manage authentication modules.

Support for Bitbucket Cloud pull requests

TeamCity already supports monitoring pull requests in GitHub, GitLab, Azure DevOps, and Bitbucket Server. And now – in Bitbucket Cloud.

Bitbucket Cloud pull requests

When you send a pull request to a Bitbucket Cloud repo, TeamCity will detect it, run a new build, and then display the pull request results. For this to work, you need to configure the Pull Requests build feature and a VCS trigger.
Note that this feature works a bit differently with Bitbucket Cloud than with other VCSs. Since Bitbucket Cloud does not create a dedicated branch per pull request, TeamCity runs builds on the source branches of pull requests and monitors only the source repository (forks are not supported).

See more details.

JetBrains Space support in Commit Status Publisher

The Commit Status Publisher build feature can integrate with JetBrains Space. With this feature, TeamCity builds can automatically publish their statuses to a JetBrains Space project in real-time.

JetBrains Space support in Commit Status Publisher

Read how to configure this integration.

Experimental UI updates

Our experimental UI is a work in progress: we introduce the changes in the early stages of development so you can already benefit from the new features. In each release, we polish already existing experimental pages and reproduce all the important classic features in the new UI. Our roadmap strongly depends on our users' feedback.
In version 2020.2, we added the Test History and Build Queue pages, implemented the full-text search in the build log, and improved the Dependencies tab of the build results.

If any of the familiar features are missing, you can switch an experimental page to the classic UI with the mammoth.png button, or turn off the experimental UI on the server completely in My Settings & Tools.

Experimental Test History page

The highly demanded Test History page gets a fresh look in this release. Now, you can see the detailed test statistics without switching to the classic mode.

Experimental Test History page

Full-text search in build log

You can now search through a build log regardless of how much of it is already loaded in the UI.

Search in experimental build log

Updated Dependencies display

We received lots of requests to show queued builds in the experimental UI representation of a build chain timeline. In this release, we've updated the build chain display to make it more informative:

  • The Dependencies | Timeline view shows all dependencies of the current build, including queued ones.

  • The Dependencies | Chain view displays a full build chain. You can see all builds that depend on the current one and promote the current build to them, as in the classic UI. If a build is composite, you can also group it right from this view.

Experimental build chain

Plugin support in Experimental UI

Now, you can write plugins for the experimental UI using modern web technologies and different frameworks. See this blog post for more details.

Experimental Build Queue page

We are actively working on the new representation of the build queue. It is still in progress and not displayed by default yet, but you can already switch to it by clicking the test-tube icon in the upper right corner of the screen.

The new sidebar is of great help to our users on the Projects and Agents pages. Now, it is available for the Queue page as well, which is most helpful for big installations with many agent pools.

You can also click any build in the queue to see its details:

Experimental build queue

In our future releases, we will polish the new queue representation and enable it by default in the experimental UI.

Customizable clean-up schedule

TeamCity server clean-up becomes more flexible with the support of cron-like expressions. You can customize the schedule so the clean-up starts with any necessary regularity: for example, on weekends or twice a day.

Cron expressions in clean-up

Remember that too frequent clean-ups might extensively load the CPU, and too rare clean-ups take more time and might lead to garbage accumulation. We recommend keeping the clean-up schedule balanced. In most cases, a daily clean-up would be enough, but highly-loaded installations might require running clean-up more frequently.

Time-limited access tokens

TeamCity can generate time-limited access tokens. You can use these tokens in scripts or other REST API requests to grant temporary access to the TeamCity server. After the token’s time limit expires, TeamCity will automatically revoke its access.

To add a new token, go to My Settings & Tools | Access tokens:

Temporary access tokens

Editing project settings on secondary nodes

TeamCity 2020.2 adds a new responsibility for secondary nodes. If granted to a node, it allows UI actions: running, stopping, tagging, commenting builds, and much more. The list of supported UI actions now also includes editing projects and build configurations (with a few limitations, such as editing cloud profiles).
Disabling this responsibility will switch a secondary node to a read-only mode.

See also upgrade notes.

Monitoring disk usage in external storage

An increasing number of our users prefer storing build artifacts in cloud – for example, in Amazon S3. However, it was not previously possible to see what amount of data is stored there.

The Disk Usage report now supports external artifact storage. It shows the amount of data stored in each configured storage or in all of them at once. Besides, if you had several artifact directories configured for the local storage, you can now also see this report separately for each directory.

On the Administration | Disk Usage page, you can switch between the detected storages and see detailed reports:

External storage in Disk Usage report

Identifying builds with custom settings

It is now easier to distinguish "custom" builds from regular ones. If a build was run with custom parameters or artifact dependencies, or not on the latest commit, TeamCity will visually mark such build. It will show the respective icon and hint opposite this build in the build list:

Custom build hint

and in the build results:

Custom build hint

Click the link in the hint to open the related tab of build results.

Muting failed tests after successful retry

Some builds can retry tests if they fail. This is most convenient for flaky tests. Such tests can alternately fail and succeed when applied to the same source revision, and you might want to exclude their influence on the build status.
Now, if test retry is enabled in your build, TeamCity will mute a failed test if it eventually succeeds during the same build run. This test will not affect the build status, and the build will finish successfully given it has no other problems.

Muted by test retry

See more details in the documentation.

Other improvements

  • Source branch filter for pull requests
    TeamCity can filter pull requests not only by the target but by the source branch. It allows you to easily eliminate certain draft branches from the scope of monitoring.
    Note that this filter is not applicable to Bitbucket Cloud as TeamCity monitors pull requests directly on their source branches.

  • Passing NuGet packages between build steps If you need to publish NuGet packages and then use their contents within one build, you want to guarantee they are published and indexed on time – and not at the build finish. Previously, it required using a NuGet Publish step. Since this release, a build step can send the ##teamcity[publishNuGetPackage] service message instead. This ensures the NuGet packages are published in all configured NuGet feeds right at the end of the current build step and are available in the following build steps.

  • Faster cold start of agent Docker containers
    Since this version, TeamCity agent Docker images are based on the full agent distribution. The full agent contains all bundled plugins. This significantly speeds up the agent cold start because the full agent doesn't need to synchronize all plugins with the server. When launched, it will only download external plugins or tools installed on your server, if any.
    Please note that this improvement is effective only if the Docker image matches the server version.

  • Easier Perforce SSH root configuration
    If a VCS root of your project connects to Perforce via SSH, TeamCity will automatically establish a trusted connection with it. The p4 trust command is now sent every time you test a Perforce connection or a build agent checks out from Perforce.

  • Limiting the number of artifacts published per build
    This helps prevent memory consumption and performance problems if multiple builds publish many artifacts in parallel.
    This number is set to 1000 in all new installations. On upgrade of an existing TeamCity installation, this number will stay unlimited. You can limit the value in Administration | Server Administration | Global Settings. Note that this limit does not consider hidden artifacts.

  • Execution timeout for composite builds
    When a composite build comprises a build that cannot start (for example, it has no compatible agents), this composite build might run forever until it is terminated manually. Now, you can set an execution timeout for such build so it fails automatically after being unable to start for a long time.

  • Support for an S3 path prefix
    You can now set a path prefix when configuring an Amazon S3 artifact storage. This allows using the same S3 bucket for all TeamCity projects and configure prefix-based permissions.

  • Updated pull request icons
    Icons representing pull requests in build results are now larger and change color depending on the pull request state, helping you to identify its status quicker.

  • Health report about insecure Tomcat connection configuration
    If the server is installed behind a reverse proxy providing HTTPS access to the TeamCity server, TeamCity now checks if the secure="true" and scheme="https" attributes are present in the Tomcat connection. If these attributes are missing, TeamCity will display the respective health report.

  • No default Gradle build file value
    Previously, the Build file field of the Gradle runner was set to build.gradle by default. We have removed this default value as some users rely on custom names of build files and prefer to let Gradle decide what file to choose.
    If you use build.gradle as your build file, all will continue to work as before this update.

  • REST API updates:
  • The .NET build runner now supports earlier versions of Visual Studio and MSBuild. Currently supported versions are: Visual Studio 2010 or later, MSBuild 4 / 12 or later.

  • To see all bundled tool updates, read our upgrade notes.

  • Version 2020.2 comes with ~30 performance fixes in various pieces of functionality (for example, in the Custom Run dialog).

Fixed issues

See TeamCity 2020.2 release notes.

Upgrade notes

Before upgrading, we highly recommend reading about important changes in version 2020.2 comparing to 2020.1.x.

Previous releases

Roadmap

See the TeamCity roadmap to learn about future updates.

Last modified: 24 November 2020