What's New in TeamCity 9.1

Unidirectional Agent-Server Communication

Traditionally TeamCity requires two HTTP connections between the server and an agent: the server creates an HTTP connection to the agent and sends commands, like start/stop build, etc.; the agent also establishes an HTTP connection to the server and sends build results. Only the agent-to-server connection can be configured over HTTPS: it is not possible to configure HTTPS for the server-to-agent connection.

Now only the agent-to-server HTTP connection is required, which means that:

• it is possible to fully secure the communication between the agent and the server using the HTTPS protocol

• an agent which is inaccessible for the TeamCity server (because of the firewall on the agent or its deployment to a private network) can now work with the server.

The communication protocol used by a particular agent can be viewed on the Agents\ | <Agent Name>\ | Agent Summary tab, the Details section.

Versioned Settings Improvements

We have made significant improvements in versioned settings for projects.

Selecting Project Settings to Run a Build on: "True" Historical Builds and more

Now TeamCity can be configured to use different settings to start builds in projects where versioned settings are enabled, which means you have the following possibilities at hand:

• it is possible to configure on the project level whether builds of the current projects will use the current build configuration settings or whether the settings from VCS will be preferred. When the settings from your VCS are used, you can run a "true" history build, i.e. the build using an older revision of the sources can now be run on the project settings that existed on the server when the selected source code changes were made.

• if you are using TeamCity feature branches, you can define a branch specification in the VCS root used for versioned settings, and TeamCity will run a build in the branch using the settings from this branch

• you can now start remote run/pre-tested commit with changes made in the .teamcity directory in your IDE, and these changes will affect the build behavior

Known Limitations

The following changes will be ignored:

• changes in snapshot dependencies: TeamCity will continue reading snapshot dependencies settings from the build configuration

• changes in build features working on the server (Automatic Merge and VCS Labeling)

• changes of the attached VCS roots and VCS checkout rules

• changes of some settings which do not affect the build behavior on an agent, for instance, build triggers, general settings like limitation on a number of concurrently running builds, remote run restrictions.

Versioned Project Settings in Subversion and Perforce

Now TeamCity allows storing the project configuration settings in a Subversion and Perforce version control repository. Previously, the only supported version controls were Git and Mercurial.

The settings are stored in the .teamcity directory in the root of the repository.

Enhanced .NET tools Support

Support for the Latest Versions of Microsoft Tools

The latest versions of all tools included in the Visual Studio 2015 lineup (namely Visual Studio 2015, MSBuild 2015, TFS 2015, MSTest 2015 (14.0), and FxCop 2015) are now supported by TeamCity.

Windows PowerShell 5.0 is also supported.

Visual Studio Tests Runner

Visual studio comes with two very similar test runners - MSTest and VSTest. TeamCity supports MSTest out of the box; for VSTest a separate plugin had to be installed. Now we combined them into a single Visual Studio Tests runner. Note that after upgrade to TeamCity 9.1, MSTest build steps are automatically converted to the Visual Studio Tests runner steps, while VSTest steps remain unchanged.

Support for NUnit 3.0

The TeamCity NUnit runner supports NUnit 3.0. now. Starting with NUnit 3.0.0 Beta 2, NUnit detects if it is run by a TeamCity build agent and automatically switches to reporting test runs using TeamCity service messages.

As a coverage engine, JetBrains dotCover only is supported for NUnit 3.0.

UI Improvements and Usability

Administrator-defined Ordering of Projects and Build Configurations

By default, TeamCity displays projects, their subprojects, and build configurations on the Projects Overview page in the alphabetical order. Starting from this release, project administrators can apply custom ordering to subprojects, and build configurations of a project on the Project Settings page and use it as the default one for all the team members, thus saving them the effort of defining the order manually. Individual users can still manually tweak the display using the up-down button on the Configure Visible Projects pop-up.

Specifying TeamCity Data Directory on the TeamCity First Start Page

The configuration of TeamCity data directory has been moved from the installation wizard to the TeamCity startup screens. The TeamCity data directory path specified on startup screens will be stored in the <TeamCity installation directory>/conf/teamcity-startup.properties file.

If the TEAMCITY_DATA_PATH environment variable is specified, the value of this variable will be used as the path to the data directory for compatibility reasons.

Create Build Configuration from URL

In addition to creating a project from URL, TeamСity now comes with an option to create a build configuration from a VCS URL. All you need to do is enter a VCS URL in the create configuration wizard, select default options to create a build configuration and that's it!

Schedule Trigger Improvements

TeamCity has different triggers suitable for various use cases, and yet some of the cases are hard to automate. To cover the scenarios when a build chain should be continued automatically based on some event, we added a new option to the Schedule Trigger. Now the Schedule Trigger can watch builds in other build configurations and trigger a build if these builds change. The watched build is specified similarly to selecting a build in the artifact dependency.

To continue a chain once some build in the chain finishes, we recommend using the improved Schedule Trigger rather than the Finish Build Trigger due to limitations of the Finish Build Trigger.

Multiple Artifact Directories Paths

By default, TeamCity stores build artifacts in <TeamCity data directory>/system/artifacts. Now the storage is not only configurable, but also scalable: you can use multiple locations (internal or external) for your artifacts and conveniently configure the paths to the storage using the Administration | Global Settings in the TeamCity UI.

If a new build starts, its artifacts are published into the first directory in the list. When looking for artifacts of earlier builds, TeamCity will go through the list of the artifact directories to locate the directory where build artifacts are stored.

Restricting Personal Builds

A new build option in the General settings of a build configuration allows you to restrict running personal builds. It is useful to disallow remote runs with personal changes from IDEs for important build configurations like deployment ones. By default, triggering personal builds is enabled; uncheck the allow triggering personal builds option to disable it.

ANSI-style Coloring in Build Logs

TeamCity build logs now supports ANSI color escape sequences. The logs also render clickable hyperlinks now.

Truncated Paths to Build configurations

Instead of showing the full path to a build configuration in the web interface, the project name part of the path is truncated to < ...>.

New Build Features

SSH Agent

This new build feature runs an SSH agent with the selected uploaded SSH key during a build. When your build script runs an SSH client, it uses the SSH agent with the loaded key. You no longer need to manage SSH keys on the agent manually.

The first time you connect to a remote host, the SSH client asks if you want to add a remote host's fingerprint to the known hosts database at ~/.ssh/known_hosts. To avoid such prompts during a build, you need to configure the known hosts database beforehand. If you trust the hosts you are connecting to, you can disable known hosts checks:

• either for all connections by adding something like this in ~/.ssh/config:

  Host * StrictHostKeyChecking no

• or for an individual command by running an ssh client with the -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no options. You can find more information in the man pages for ssh, ssh-agent and ssh-add commands.

File Content Replacer

TeamCity has a general file content replacer now. Compared to AssemblyInfo Patcher, the new feature enables you to change a wider range of values for the duration of the build in files specified by the user. It provides value pre-sets for replacement; custom values can also be used. The changes are valid for the duration of the build; on build finishing, the changed source files are reverted.

REST API Improvements

• /app/builds request supports more abilities to filter builds: "failed to start" builds via failedToStart:any/failedToStart:false locator, include queued and running builds via state:(any) locator, get builds within a build chain via snapshotDependency:(to:(<build locator>)),defaultFilter:false locator, etc.

• ability to get build's artifacts in archive via /app/rest/builds/<build locator>/archived request

• ability to change build parameter type specification

• ability to list only not archived projects via archived:false projects locator

Other Improvements

• Bundled Ant upgraded to version 1.9.6. Ant-runner build steps require Java 1.5 at least.

• The bundled Java has been updated to version 1.8.0_45

• Bundled IntelliJ IDEA is upgraded to version 14.1.4

• Xcode 7.0 is supported (tested with 7.0 beta)

• The default Subversion working copy format has been changed to 1.8

• logging preset selected on the Diagnostics page is preserved on server restart

• More reliable TeamCity server shutdown

• The TeamCity Web UI now allows specifying custom command line parameters to pass to dotCover.

• The Run Custom Build dialog allows adding a build to favorites using the corresponding checkbox on the Comments and Tags tab.

• Simple Build Tool (Scala) plugin is now bundled with TeamCity

• It is now possible to specify multiple VCS usernames for each level (default, VCS type or VCS root)

• SSH Key support for Subversion checkout on agent TW-35092

• It is now possible to identify not-actual tests on the Investigations page

Previous Releases

What's New in TeamCity 9.0