Child pages
  • TeamCity 3.1 EAP (build 6658) Release Notes
Skip to end of metadata
Go to start of metadata

As we are approaching 3.1 release, this EAP represents the state of the TeamCity 3.1 as it will be released after a short stabilization period.

TeamCity 3.1 is a maintenance release with lots of bugs fixed and some minor features added.

New Notification Options: notify only on build state change

Now it is possible to receive notifications only when the build status changes. Two options are added: "Limit to only the first successful build after failed" and "Limit to only the first failed build after successful":

Agents Load Statistics

In order to better analyze TeamCity build agents load, we have introduced Agents statistics that allows to visualize agents load during the specified time period (this statistics is visible to non-Guests in Professional edition and to users with Developer or Agent Manager roles in Enterprise edition):

More .Net Tools Support

Now you can specify in what mode (x86 or x64) to run the NUnit tests.
Also NUnit 2.4 is now supported. Please refer to the appropriate documentation section for configuration instructions.

NAnt 0.86 support is added.

Sending Service Messages via Standard Output

As TeamCity reports tests on-the-fly and not after all the tests were finished, every testing framework needs it's own support for the feature.
In this release we are introducing an easy way to report running tests information to TeamCity: just print specially formatted message to the standard output of the build process and TeamCity knows there is a test!

Here is the list of supported service messages:

Test suite messages:
##teamcity[testSuiteStarted name='']
##teamcity[testSuitFinished name='']

Test messages:
##teamcity[testStarted name='testname']

"testFinished" message should be sent for every test (successful and failed)
##teamcity[testFinished name='testname']
##teamcity[testIgnored name='testname' message='ignore comment']

Test output reporting (to be shown as the test result is the test fails). A test should have no more then one testStdOut and one testStdErr message
##teamcity[testStdOut name='testname' out='text']
##teamcity[testStdErr name='testname' out='text']

##teamcity[testFailed name='testname' message='failure message' details='stack trace']
##teamcity[testFailed type='comparisonFailure' name='testname' message='failure message' details='stack trace' expected='expected value' actual='actual value']
(actual and expected attributes are used when opening the test in the IDE)

Please note that each message should be followed by a newline.

During-the-Build Artifact Publishing

Another cool feature of service messages is that now you can publish build artifacts, while the build is still running.
Just output the following line:

##teamcity[publishArtifacts '<path>']

And the files matching the "path" will be uploaded and visible as artifacts of the running build.

Please note that publishing artifacts process can affect the build because it consumes network traffic and some disk/CPU resources (should be pretty negligible for not large files/directories).

Artifacts that are specified in the build configuration setting will be published as usual.

UI Enhancements

Now you can navigate to any build configuration from any page. Projects tab has drop-down list:

And all the information of a queued build (start estimate, agent assignment) is now available right from the Projects page:

Other Improvements

Build Working Directory

Build runners now support Build working directory setting.
The build script will be run from the specified directory set as current. Defaults to checkout directory.

Different Levels of Cleanup

Now you can tweak what data should be deleted. The available option are:

  • Artifacts only. Build artifacts are removed from disk, but build is still listed in the history table and build results are available.
  • Remove build from history. (Default) After this cleaning the build will only be visible in the statistics charts.
  • Full build clean-up. The build is removed at all.

Filter by Agent

Now you can search builds ran on specific agent using "@<agent_name>" syntax. This works in the quick search field by the right side of the header.

In addition, you can filter history of builds of particular build configuration by part of the agent name.


  • Basic support for accurate tests reporting running in parallel (builds using parallel Ant task or TestNG parallel running mode should correctly report failed tests and their output)
  • In Enterprise edition, "View Agent Details" permission is added (by default the permission is included in the Project Developer, Project Administrator, Agent manager and System administrator roles), in Professional edition all users except Guest can now view the Agent details.

Since this release you also can:

  • review Duplicates and Inspections results filtered by directories (work on UI is still in progress, feedback is welcome);
  • specify notification rules for all the projects. Rules to specific project or build configurations will override this "All Projects" rule;
  • use TLS (SSL) connections to send e-mail notifications;
  • schedule builds with CRON-like expressions;
  • review "Time to fix tests" statistics chart;
  • enjoy syntax highlighting in Duplicate Code fragments viewer (Duplicates Finder runner build results);
  • in Enterprise TeamCity version, use Windows domain authentication on Linux computers.

Known Issues with this Build

  • If there are build configurations with lots of tests (millions) and there are lots of builds in the history, you can experience long loading times of the Statistics page after the server start.
  • No labels