Skip to end of metadata
Go to start of metadata
You are viewing documentation of TeamCity 6.5.x, which is not the most recent released version of TeamCity. Please refer to the listing to choose another version.

Table of Contents

Less restrictions in Professional Edition

Starting with TeamCity 6.5 all Professional Edition restrictions were removed except one: the maximum number of build configurations (20).
TeamCity Professional edition users now have:

  • Unlimited number of users.
  • Ability to use any authentication scheme.
  • Adjustable per-project permissions.

This basically means that all features of the Enterprise Edition are now available in Professional Edition.

Remote run on changes in DVCS branches

TeamCity provides a more natural way to start remote run builds with distributed version control systems. As opposed to usual version control systems, in DVCSs branches are used extensively. Usually developers implement some feature in their own branch and then push their changes to the master branch in main repository. It is tedious to create separate build configurations in TeamCity server for each such branch, that is why now there is a better solution.

If you are using Git or Mercurial in your project you can add special build trigger called "Branch Remote Run" to a build configuration. This build trigger will watch for commits into the branches of this build configuration VCS roots. If a commit is detected and if branch name matches to specific pattern, trigger will add personal build to the build queue.
Learn more

Enhanced Build Parameters

Parameterized Version Control System roots

TeamCity now supports parameter references in text fields in VCS root settings (except password fields). This way you can have a VCS root shared among several projects and customize it significantly in certain build configurations. It is also possible to start custom build and change some VCS parameter which, for example, affects a branch name. But in this case it is recommended to run such build as personal build so that it won't affect build history for other users.
Learn more about build parameters

Project-level parameters

You can specify project-level parameters which act as default parameters for each build configuration and template in the project.
Learn more about build parameters

Parameters completion

Anywhere you see the icon you can use parameters completion. Just type % or click the icon, and choose required parameter from the list.

Note that parameters completion also works in "Run custom build" dialog.

Parameters of a build

Each build now publishes the final set of parameters passed to it when it started on agent. You can see all of them on the "Build Parameters" tab of the finished build.

Restyled web interface

TeamCity 6.5 introduces new, restyled web interface - more lightweight, more modern looking and hopefully more convenient.

Note, that we no longer load content of the projects collapsed on the Overview page. This significantly quickens up the Overview page.

Tests grouping

In many places where lists of tests are shown, the tests can now be grouped by package. This applies to build results page, Current Problems page, My Changes and so on. This is intended to help identifying common problems faster.

Test failures muting

TeamCity provides a way to mute some of the failing tests so they won't affect build status allowing to manage your projects more efficiently. This feature is useful when some tests fail for some known reason, but it is currently not possible to fix them. For example, responsible developer is on vacation, or you are waiting for the system administrators to fix the environment, or the test is failing intentionally, for instance, if required functionality is not yet written (TDD), or the test is flickering (fails from time to time for unknown reason). In these cases you can mute such failure to avoid unnecessary disturbance of other developers.

Test muting is potentially dangerous operation, that is why it is not available to Project Developer role by default. Only users with Project Administrator role can mute tests in the project.
Learn more

Responsibility renamed to Investigation

Based on feedback from our users we decided to rename "Responsibility" to "Investigation". The main reason for such rename is to avoid unnecessary friction in teams when someone assigns other developer as responsible. To our opinion term "Investigation" sounds more polite.

We also reworked "Bulk mode" for investigator assignment. Now, anywhere where test grouping present you'll see "Bulk mode" link which adds checkboxes for the tests.

Reworked My Changes page

Detailed data for each change is now shown on tabs. You can change tabs for the currently selected change with Tab/Shift+Tab keyboard shortcut. We also added a tab with suspicious builds with your change. For personal changes, all builds are shown. Problems which have an investigator are not considered critical (unless you are investigating the problem).

Audit of project configuration changes

Audit log is now able to track changes in the project and build configuration settings. In the project or build configuration administration pages you can now see the name of the user who modified project or build configuration, as well as a link to the changes themselves. Since project and build configuration settings are stored on disk in plain xml, the link will just open the usual TeamCity diff window showing changes in these xml files.

Build steps

TeamCity 6.5 supports names for Build steps. The names are shown in the build log and in Project administration screens.

Additionally, you can now copy build steps, and reorder them even if build configuration is inherited from a template. This means that in the inherited build configuration you can insert custom build steps at any place, before, between, or after the inherited steps, in any order. However, the order of inherited build steps can be changed in the template only.


Agents JVM upgrade

TeamCity code base is evolving. Right now TeamCity server and agents can work under Java 1.5, but at some point we can decide to switch to Java 1.6 or later. Such switch is good not only for us, TeamCity developers, but for our users too, because some of the Java 1.6 features can finally provide additional functionality for TeamCity users. Not to mention that usually more recent versions of Java are faster than previous versions. It is not a problem to upgrade Java used by the server, but it is not so easy to upgrade Java used by agents, simply because there can be a lot of them.

In TeamCity 6.5 we added a feature which can simplify task of agent Java upgrade. TeamCity is able to detect version of Java used by the agent and offer a switch to Java 1.6 if such Java is found on the agent.

Remote build agent installation

TeamCity provides new, experimental way to install build agents on the machines in your network, or in the cloud. The agent distribution is pushed on a Unix machine (by SSH) or on a Windows machine (with help of Sysinternals psexec), is installed there, and is configured and started automatically. For this to work, TeamCity needs to know credentials of the user on a remote machine with permissions necessary to install software. Also since TeamCity is using SysInternals psexec, push of the agent on Windows machine is only possible if server is installed on Windows.
This feature also integrates with Amazon Cloud functionality. You can create a preset for Agent Push, and specify this preset in Cloud profile settings. In this case, when TeamCity starts an image in the cloud, the agent is pushed on the image automatically, so you do not need to install it on the image and modify build agent configuration to specify correct server URL.
Learn more

Agents parameters report

With the help of this report administrator can find which agents have particular property and with which values.

Amazon Elastic Cloud integration improvements

We reworked user interface for the Elastic cloud profile setup. Now, when you setup new Cloud profile, TeamCity will fetch many Amazon EC2 parameters from the Amazon itself, so you'll see actual values for availability zones, security groups, and so on. Additionally, our integration with Amazon EC2 now supports Virtual Private Clouds.

IDE integration

VS-addin integrates with JetBrains dotCover 1.1

New version of TeamCity VS-addin can download dotCover test coverage snapshots from the TeamCity server and open them right in the dotCover installed in your Visual Studio locally. Thus there is no need to run coverage locally. Just take it from the server. This only works with JetBrains dotCover 1.1.

Filtering of data by current project

By default, data shown by IDE plugins (projects, changes, and so on) are filtered by currently opened project. So if you have a project opened, you'll see a reduced set of build configurations, i.e. you'll see only those configurations which are building the sources of the project opened in IDE. In previous versions of IDE plugins we had this functionality in "Remote Run" dialog only. Now it affects the whole UI of the IDE plugin.

Note, that per-project filtering can be disabled via plugin settings.

.NET specific features

AssemblyInfo patcher

In .NET world to set a build number to an assembly, you need to patch AssemblyInfo.cs files. New build feature simplifies this procedure. Just specify version format and the rest will be done automatically.
Learn more

PowerShell runner

You could start PowerShell scripts with help of command line runner in earlier versions of TeamCity. But since PowerShell is a very popular tool for .NET developers we decided it worths to support it natively in TeamCity.

MSpec test runner

Among BDD frameworks for .NET MSpec is probably the most popular. The official builds of MSpec are built using TeamCity. And now we have built-in MSpec runner designed specifically to run MSpec tests.
Learn more

.NET process runner

.NET process runner is able to run any .NET assembly under selected .NET Framework version and platform, optionally with .NET code coverage. For example, you can use it to run xUnit, Gallio or other .NET test runner, for which TeamCity does not have dedicated runner.
Learn more

XML Report Processing build feature

XML Report Processing functionality has been extracted to separate build feature. The advantage is that you can keep all XML Report settings in one place (in TeamCity 6.0 they were distributed among build steps).

Additionally this build feature has got support for Google Test and JSLint reports.

Disk Space build feature

This build feature is able to check whether an agent has disk space required for the build, and if not, it will delete some files on agent (like inactive checkout directories of other projects, artifact dependencies caches and so on) to satisfy build disk space requirements.

Other improvements

  • IntelliJ IDEA plugin does not fetch data from TeamCity server in collapsed state.
  • Configuration parameters can now be changed for remote run build started from IDE.
  • TeamCity is able to take thread dumps from builds running .NET 4.0 processes.
  • To simplify diagnostics of problems with agents, agent logs can now be seen from the web UI, and thread dump of the agent process can be taken from the web UI too.
  • Agent upgrade procedure improved, may result for slightly slower agents upgrade for the first time.
  • In previous versions of TeamCity if build contains a lot of changes, chances are you won't see your changes in the changes popup because the number of shown changes is limited. This is not so anymore. Now if build contains your changes, you will always see them in the changes popup.
  • Relative time is shown on the overview page for the finished builds.
  • IntelliJ IDEA project runner now supports tests reordering (for JUnit and TestNG test frameworks).
  • Windows tray notifier has been rewritten.
  • Artifact dependency resolver was rewritten, we do not use Ivy for this task anymore, but we maintain compatibility with Ivy.
  • Artifact dependencies now support dependency on a build with a given tag.
  • TeamCity should not update timestamps of downloaded artifacts if artifacts were not changed since the previous build in the same directory.
  • Scheduling trigger can trigger builds on all compatible and enabled agents at once.
  • To avoid user interface clutter custom build settings in "Run custom build" dialog are distributed between tabs.
  • Build's statistical values can be obtained via REST API.
  • resolved issues

Previous Releases

What's New in TeamCity 6.0