What's New in TeamCity 2019.1

We have reworked the documentation for TeamCity 2019.1 to create a better user experience and ensure a common look and feel across the documentation of all company products.

The main product documentation is accessible on the new documentation website.

The Plugin Development Help is now in a separate location and its source files have been moved to the public GitHub repository so our community can contribute to it.

See the documentation for previous versions.

The new TeamCity version comes with the reworked UI aiming at improving your experience with the product.

• New Sidebar: You can now easily access and search all your projects and build configurations from the sidebar, tag build configurations or whole projects as your favorites to see them at the top of the sidebar. New changes, build status, new tests, and running builds: all are now visible.

• The reworked Project Home page provides a dashboard-style view over your build configurations. Each configuration gets its own card which displays a histogram with up to 14 of the latest builds. The status, the build time as well as the time in the queue are also available. Clicking an individual card takes you to the overview of this build configuration.

• Revamped Branches Tab: Branches are now split into categories, and you can expand and collapse them as needed. This helps you keep an overview of your branches and browse them conveniently.

  

• Expandable build row: now, TeamCity can show more about builds on a page, and if you need details on a particular build, clicking it will expand the row allowing more information.

• The new UI is in the experimental stage, and you can switch to it using the icon in the upper right-hand corner of the screen. There is also a new setting in your profile enabling the experimental UI by default. As not all the features are supported by the new UI, it is easy to go back to the classic TeamCity style when needed.

TamCity 2019.1 supports GitLab. It allows creating connections to GitLab.com and GitLab CE/EE so you could easily select a predefined GitLab repository when creating a new project or a build configuration.
To be able to authenticate to GitLab during the connection, register an OAuth application in GitLab with the api and read_repository scopes and generate a secret and an application ID.
Enter the secret and application ID, along with the GitLab server URL, when adding a new connection.

Now the Pull Requests build feature can detect pull requests created in Bitbucket Server.
To add a Bitbucket VCS root, select Bitbucket Server as a VSC hosting type and configure the connection parameters:

• Authentication Type: VCS root credentials or username/password

• Filtration by target PR branches

• Bitbucket Server's base URL

To improve scalability of TeamCity, we're working on the ability to set up a cluster, where the main node distributes different responsibilities among other nodes and also handles such tasks as upgrading, licensing, diagnostics, and server configuration. Such multinode setup implies that all secondary nodes are uniform and can perform all tasks in an interchangeable way.
In addition to the tasks that can already be performed by a secondary node, in this version secondary nodes can be assigned the "processing the build lifecycle" responsibility, which releases the main server from the build-related tasks, such as processing builds messages coming from agents, and allows you to significantly increase the number of agents.
As a result, it is possible to start a single secondary node and assign several responsibilities to it or distribute these responsibilities between several secondary nodes:

• VCS changes collecting

• running builds processing

• serving as a read-only backup node: providing the user interface in the read-only mode

Build artifacts may comprise distribution packages, log files, reports, and so on, taking up a lot of storage space. When a build fails often, you may want to restrict artifacts publishing to successful builds only in order to save disk space.
In other cases, you may need to investigate artifacts even if a build has been interrupted.
To support all these scenarios, we have added two new options for publishing artifacts to the General Settings of a build configuration.

Now you can choose when to publish artifacts:

• Even if build fails (default): as in the previous versions of TeamCity, artifacts are published at the last step of a build if all previous steps have been completed, successfully or not. If the 'stop' command is issued, artifacts are not published.

• Only if build status is successful (new): artifacts are published at the last step of a build if all previous steps have been completed successfully. TeamCity checks the current build status on the server before publishing artifacts.

• Always, even if build stop command was issued (new): artifacts are published for all builds, even for interrupted ones (for example, after the 'stop' command was issued or after the time-out, specified in the build failure conditions).

TeamCity now supports the Go language:

To build Go projects:

1. Make sure a Go compiler is installed on an agent.

2. Add the 'Golang' build feature to a build configuration.

To see Go tests in the TeamCity UI, run them with the -json flag added to the Command Line build runner's script: go test -json or add the env.GOFLAGS = -json parameter to the build configuration.

note

Make sure you use only one of the methods to set the -json flag. Setting it in both build parameters and the runner's script will make Go fail to build.

In a TeamCity build chain, all builds linked via snapshot dependencies use the synchronized revision of the source code, but in some cases this may be undesirable.
In this version you can disable revision synchronization in a snapshot dependency via the Enforce revision synchronization option, for example, when promoting an older build to a deployment build configuration. The build will be run using the latest deployment scripts.

We have added a branch filter to the version control settings of a build configuration, similarly to filters in build triggers or test details. In the previous versions of TeamCity, VCS settings allowed disabling builds in the default branch only, but the branch filter offers a more flexible approach. To filter branches, use the syntax described in Configuring branches.

The VCS branch filter is applied before any other branch filter and limits branches shown in the custom build dialog, branches visible to triggers, and changes from snapshot dependencies.

If a user's password is compromised and Built-in Authentication is enabled on the TeamCity server, changing a user password does not mean that the user is logged out of all current sessions in progress, which is a potential security risk.
Now there is a new option in your user profile, Log out of all sessions, forcing TeamCity to invalidate all user sessions with the user set, including the current one. The administrator account also has an option to force the user to log out of all sessions. It is also possible to log off all users using the corresponding option on the Administration | Authentication page.

In addition to basic authentication via credentials, TeamCity now supports authentication based on permanent access tokens. With tokens, you don't need to expose a user login and password in scripts. Tokens are also useful for the REST API authentication.
You can enable/disable the Token-Based Authentication module in the advanced mode of the Authentication page:

If you are using the TeamCity integration with YouTrack, you should know that the login-password authentication is deprecated and soon will no longer be supported by YouTrack.

The TeamCity-YouTrack integration now supports for token-based authorization in REST API calls. It is recommended that you obtain a token and specify it in the connection settings to your issue tracker on the Project Settings | Issue Trackers page.

When you need to cancel a build from a script, for example, a build cannot proceed normally due to the environment, or a build should be canceled form a subprocess, it is possible to do it via the TeamCity REST API passing the build ID, the server URL, as well as the authentication parameters (username and password) to the script.
Now TeamCity offers a more elegant way of using a service message to do that just add a line to your build script telling TeamCity to cancel the build. If required, you can re-add the build to the queue after canceling it:

echo ##teamcity[buildStop comment='canceling comment' readdToQueue='true']

Read more about TeamCity service messages.

Previously, build agents downloaded all available tools from the server right after the server upgrade, which could significantly load and slow down the server. To reduce the agents' requests impact on the server and speed up the agents' upgrade, agents now download tools from the server only when starting the first build that requests these tools. The downloaded tools are stored on agents so builds don't spend time on downloading them again.

We have changed the local artifact repository settings selection for Maven and added an option to create a separate repository for all builds run by an agent.

Here is what changed:

• If the 'Docker Registry Connections' feature is added to a build configuration, the TeamCity server will automatically add an agent requirement for an installed Docker, so the builds will run on compatible agents only.

• Starting from this version, TeamCity supports Visual Studio 2019 in the related runners: Visual Studio(sln), MSBuild, Visual Studio Test, Inspections(ReSharper), Duplicates Finder(ReSharper).

• Investigations Auto Assigner has got a new option, 'On second failure', which prevents user assignment for the flaky tests/problems. A user is assigned to investigate a failure only when the failure repeats itself the second time in a row.

• New API for setting agent requirements based on build features.

• The former GitHub Pull Requests plugin to Pull Requests.

• The server startup performance has been improved.

• The My Investigations page now displays failures in the currently running builds.

• Build runners now support .NET Framework 4.8.

• When you use .NET CLI for running a build that tries to pass credentials via some NuGet command, you may receive one of the following errors.

  • If .NET Core SDK 2.x is installed but its version is earlier than 2.1.400:
    " Could not load file or assembly 'System.Runtime, Version=\<version\>, Culture=neutral, PublicKeyToken=\<key\> or one of its dependencies. The system cannot find the file specified. "

  • If only .NET Core SDK 3.0 is installed on your server:
    " A plugin was not found at path \<path\> if only dotnet version 3.0 is installed on an agent. "

  To fix any of these problems, we recommend installing .NET Core SDK 1.x and/or 2.1.400 or later additionally to your current SDK version.

• If you use Docker images and Windows Server 2019 with process isolation, build agents may fail to start. To work around the issue, use the hyper-v isolation for Docker/Podman containers:

  docker run --isolation=hyperv ...
  # or
  podman run --isolation=hyperv ...

Full list of fixed issues

What's New in TeamCity 2018.2