Child pages
  • Kanpur 2019.1 RC (build 65943) Release Notes

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


In this version we’ve partially addressed these cases: you can now disable revision synchronization in a snapshot dependency when promoting a build. If you disable uncheck the 'Enforce revision synchronization' box in the Add/Edit Snapshot Dependency dialogue, you will be able to promote a build (manually or via a trigger) in a dependency chain, and TeamCity will put the target build into the queue without synchronizing its code revision with other build configurations of the chain.


To be able to authenticate in 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.


If you select 'On second failure', the Assigner will be waiting until wait for the second sequential failure of a test in the current build configuration (in the default branch) before assigning investigations to a user.

Separate Maven artifact repository for all builds on agent

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:


Old option

New option



Per agent (default)

Use a separate repository to store artifacts, produced by all builds run by an agent, under the agent system directory.

Enabled “Use own local repository for this build configuration”

Per build configuration

Use a separate repository to store artifacts, produced by all builds of the current build configuration.

Disabled “Use own local repository for this build configuration”

Maven default

Use the default Maven repository location. The repository is shared between all build configurations and all agents on the machine.

Branch filter for VCS of build configuration

We have added a branch filter to 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 a 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 a the custom build dialog, branches visible to triggers, and changes from snapshot dependencies.

Cached configuration files on nodes


In TeamCity 2019.1, we have optimized this operation by creating a cache of configuration files stored under the node local data directory. The files are cached on the first node launch and then updated in runtime which makes the next launches faster.

Other improvements

  • Optimized storage Storage of VCS-related data has been optimized to improve the server performance during startup.
  • Access tokens now can be used for authentication to the TeamCity server instead of passwords.


Known issues

  • If you used access tokens in TeamCity Kanpur 2019.1 EAP3, note that they will be deleted from the database and stop working on upgrading to 2019.1 RC. Make sure to generate new access tokens after upgrading.
  • 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.