Build Script Interaction with TeamCity

If TeamCity doesn't support your testing framework or build runner out of the box, you can still avail yourself of many TeamCity benefits by customizing your build scripts to interact with the TeamCity server. This makes a wide range of features available to any team regardless of their testing frameworks and runners. Some of these features include displaying real-time test results and customized statistics, changing the build status, and publishing artifacts before the build is finished. The build script interaction can be implemented by means of:

• service messages in the build script

• teamcity-info.xml file

servMsgs Service Messages

Service messages are used to pass commands/build information to TeamCity server from the build script. In order to be processed by TeamCity they should be printed into standard output stream of the build (otherwise, if the output is not in the service message syntax, it should appear in the build log). A single service message should not contain a newline character inside it, it should not span across multiple lines.

Service messages support two formats:

• Single attribute message: ##teamcity[<messageName> 'value']

• Multiple attribute message: ##teamcity[<messageName> name1='value1' name2='value2']

Multiple attributes message can more formally be described as:

##teamcity[ messageName WSP propertyName OWSP=OWSP' value 'WSP propertyName_ID OWSP=OWSP' value '...OWSP]

where:

• messageName is a name of the message. See below for supported messages. The message name should be a valid Java id (only alpha-numeric characters and "-", starting with a alpha character)

• propertyName is a name of the message attribute. Should be a valid Java id.

• value is a value of the attribute. Should be an escaped value (see below).

• WSP is a required whitespace(s): space or tab character (\t)

• OWSP is an optional whitespace(s)

• ... is any number of WSP propertyName OWSP=OWSP'_value'_ blocks

For escaped values, TeamCity uses a vertical bar "|" as an escape character. In order to have certain characters properly interpreted by the TeamCity server they must be preceded by a vertical bar. For example, the following message:

##teamcity[testStarted name='foo|'s test']

will be displayed in TeamCity as 'foo's test'. Please, refer to the table of the escaped values below.

Common Properties

Any "message and multiple attribute" message supports the following list of optional attributes: timestamp, flowId. In the following examples <messageName> is the name of the specific service message.

Message Creation Timestamp

##teamcity[<messageName> timestamp='timestamp' ...]

Timestamp format is "yyyy-MM-dd'T'HH:mm:ss.SSSZ" or "yyyy-MM-dd'T'HH:mm:ss.SSS" (or "yyyy-MM-dd'T'HH:mm:ss.fffzzz" for .NET DateTime), according to Java SimpleDateFormat syntax e.g.

##teamcity[<messageName> timestamp='2008-09-03T14:02:34.487+0400' ...] ##teamcity[<messageName> timestamp='2008-09-03T14:02:34.487' ...]

Message FlowId

The flowId is a unique identifier of the messages flow in a build. Flow tracking is necessary for example to distinguish separate processes running in parallel. The identifier is a string that should be unique in the scope of individual build.

##teamcity[<messageName> flowId='flowId' ...]

Blocks of Service Messages

Blocks are used to group several messages in the build log.

Block opening:

 ##teamcity[blockOpened name='<blockName>']

Block closing:

 ##teamcity[blockClosed name='<blockName>']

reportingMessagesForBuildLogReporting Messages For Build Log

You can report messages for build log in the following way:

##teamcity[message text='<message text>' errorDetails='<error details>' status='<status value>']

where:

• The status attribute may take following values: NORMAL, WARNING, FAILURE, ERROR. The default value is NORMAL.

• The errorDetails attribute is used only if status is ERROR, in other cases it is ignored.

This message fails the build in case its status is ERROR and "Fail build if an error message is logged by build runner" checkbox is checked on build configuration "Build Failure Conditions" page. For example:

##teamcity[message text='Exception text' errorDetails='stack trace' status='ERROR']

reportingCompilationBlocksReporting Compilation Messages

##teamcity[compilationStarted compiler='<compiler name>'] ... ##teamcity[message text='compiler output'] ##teamcity[message text='compiler output'] ##teamcity[message text='compiler error' status='ERROR'] ... ##teamcity[compilationFinished compiler='<compiler name>']

where:

• compiler name is an arbitrary name of the compiler performing compilation, eg, javac, groovyc and so on. Currently it is used as a block name in the build log.

• any message with status ERROR reported between compilationStarted and compilationFinished will be treated as compilation error.

Reporting Tests

To use TeamCity's on-the-fly test reporting, testing framework needs dedicated support for this feature to work (alternatively, XML Report Processing can be used). If TeamCity doesn't support your testing framework natively, it is possible to modify your build script to report test runs to the TeamCity server using service messages. This makes it possible to display test results in real-time, make test information available on the Tests tab of the Build Results page.

Here is the list of supported test service messages:

Test suite messages: Test suites are used to group tests. TeamCity display tests grouped by suite on the Tests tab of the build results and in other places.

##teamcity[testSuiteStarted name='suite.name'] <individual test messages go here> ##teamcity[testSuiteFinished name='suite.name']

All the individual test messages should appear between testSuiteStarted and testSuiteFinished (in that order) with the same name attributes. Suites may also be nested.

Test start/stop messages:

##teamcity[testStarted name='testname' captureStandardOutput='<true/false>'] <here go all the test service messages with the same name> ##teamcity[testFinished name='testname' duration='<test_duration_in_milliseconds>']

Indicates that the test "testname" was run. If testFailed message is not present, the test is regarded as successful.

duration (optional numeric attribute) - sets the test duration to be reported in TeamCity UI. If omitted, the test duration will be calculated from the messages timestamps. If the timestamps are missing, from the actual time the messages were received on the server. captureStandardOutput (optional boolean attribute) - if true, all the standard output (and standard error) messages received between testStarted and testFinished messages will be considered test output. The default value is false and assumes usage of testStdOut and testStdErr service messages to report the test output.

It is highly recommended to ensure that the pair of test suite + test name is unique within the build. For advanced TeamCity test-related features to work, test names should not deviate from one build to another (a single test should be reported under the same name in every build). e.g. it's highly unrecommended to include absolute paths in the reported test names.

Ignored tests:

##teamcity[testIgnored name='testname' message='ignore comment']

Indicates that the test "testname" is present but was not run (was ignored) by the testing framework. As an exception testIgnored message can be reported without matching testStarted and testFinished messages.

Test output:

##teamcity[testStarted name='testname'] ##teamcity[testStdOut name='testname' out='text'] ##teamcity[testStdErr name='testname' out='error text'] ##teamcity[testFinished name='testname' duration='50']

testStdOut and testStdOrr service messages report the test's standard and error output to be displayed in TeamCity UI. There should be no more then single testStdOut and single testStdErr message per test. Alternative, but less reliable approach is to use captureStandardOutput attribute of testStarted message.

Test result:

##teamcity[testStarted name='test1'] ##teamcity[testFailed name='test1' message='failure message' details='message and stack trace'] ##teamcity[testFinished name='test1'] ##teamcity[testStarted name='test2'] ##teamcity[testFailed type='comparisonFailure' name='test2' message='failure message' details='message and stack trace' expected='expected value' actual='actual value'] ##teamcity[testFinished name='test2']

Indicates that the test with the name "testname" has failed. Only single testFailed message should appear for a given test name. message contains a textual representation of the error. details contains detailed information on the test failure, typically a message and an exception stacktrace. actual and expected attributes should only be used together with type='comparisonFailure and can be used for reporting comparison failure. The values will be used when opening the test in the IDE.

Here is a longer example of test reporting with service messages:

##teamcity[testSuiteStarted name='suite.name'] ##teamcity[testSuiteStarted name='nested.suite'] ##teamcity[testStarted name='package_or_namespace.ClassName.TestName'] ##teamcity[testFailed name='package_or_namespace.ClassName.TestName' message='The number should be 20000' details='junit.framework.AssertionFailedError: expected:<20000> but was:<10000>|n|r at junit.framework.Assert.fail(Assert.java:47)|n|r at junit.framework.Assert.failNotEquals(Assert.java:280)|n|r...'] ##teamcity[testFinished name='package_or_namespace.ClassName.TestName'] ##teamcity[testSuiteFinished name='nested.suite'] ##teamcity[testSuiteFinished name='suite.name']

Reporting .NET Code Coverage Results

You can configure .NET coverage processing by means of service messages. To learn more, refer to Manually Configuring Reporting Coverage page.

Publishing Artifacts while the Build is Still in Progress

You can publish build artifacts, while the build is still running, right after the artifacts are built. For this you need to output the following line:

##teamcity[publishArtifacts '<path>']

And the files matching the <path> will be uploaded and visible as artifacts of the running build. <path> should adhere to the same rules as Build Artifact specification on the Build Configuration settings. The message should be printed after all the files are ready and no file is locked for reading. Artifacts uploading happens in background and can take time. Please make sure the matching files are not deleted till the end of the build. (e.g. you might put them in a directory that is cleaned on next build start, How To... or use Build Files Cleaner (Swabra) to clean them after the build.)

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

Reporting Build Progress

You can use special progress messages to mark long-running parts in a build script. These messages will be shown on the projects dashboard for corresponding build and on the build results page.

To log single progress message use:

##teamcity[progressMessage '<message>']

This progress message will be shown until another progress message occurs or until next target starts (in case of Ant builds).

If you wish to show progress message for a part of a build only you can use:

##teamcity[progressStart '<message>'] ...some build activity... ##teamcity[progressFinish '<message>']

Reporting Build Status

TeamCity allows user to change the build status directly from the build script.

You can also permanently change the build status text for your build. Unlike with progressReporting, this change persists even after build has finished.

To set the status and/or change the text of the build status (for example, note the number of failed tests if the test framework is not supported by TeamCity), use the buildStatus message with the following format:

##teamcity[buildStatus status='<status value>' text='{build.status.text} and some aftertext']

where:

• The status attribute may take following values: FAILURE, SUCCESS.

• {build.status.text} is an optional substitution pattern which represents the status, calculated by TeamCity automatically using passed test count, compilation messages and so on.

• neither status, nor text attributes are mandatory

Reporting Build Number

To set a custom build number directly, specify a buildNumber message using the following format:

##teamcity[buildNumber '<new build number>']

In the <new build number> value, you can use the {build.number} substitution to use the current build number automatically generated by TeamCity. For example:

##teamcity[buildNumber '1.2.3_{build.number}-ent']

Adding or Changing a Build Parameter

By using dedicated service message in your build script, you can dynamically update some build parameters right from a build step, so that following build steps will run with modified set of build parameters.

##teamcity[setParameter name='ddd' value='fff']

When specifying a build parameter's name, mind the prefix:

• system for system properties.

• env for environment variables.

• no prefix for configuration parameter. Configuring Build Parameters.

The changed build parameters will also be available in dependent builds as %dep.*% properties.

Reporting Build Statistics

In TeamCity, it is possible to configure a build script to report statistical data and then display the charts based on the data. Please refer to the Customizing Statistics Charts page for a guide to displaying the charts on the web UI. This section describes how to report the statistical data from the build script via service messages. You can publish the build statics values in two ways:

• Using a service message in a build script directly

• provideStatsUsingFile

To report build statistics using service messages:

• Specify a 'buildStatisticValue' service message with the following format for each statistics value you want to report: ##teamcity[buildStatisticValue key='<valueTypeKey>' value='<value>']

The key should not be equal to any of Custom Chart. The value should be a positive integer value.

Disabling Service Messages Processing

If you need for some reason to disable searching for service messages in output, you can disable service messages search with the messages:

##teamcity[enableServiceMessages] ##teamcity[disableServiceMessages]

Any messages that appear between these two are not parsed as service messages and are effectively ignored. For server-side processing of service messages, enable/disable service messages also support flowId attribute and will ignore only the messages with the same flowId.

Importing XML Reports

In addition to UI XML Report Processing, XML reporting can be configured from within the build script with the help of importData service message. Also, the message supports importing of previously collected code coverage and code inspection/duplicates reports.

The service message format is:

##teamcity[importData type='typeID' path='<path to the xml file>']

where typeID can be one of the following (see also XML Report Processing):

Notes: ¹⁾ only supports specific file in the "path" attribute ²⁾ also requires findBugsHome attribute specified pointing to the home directory oif installed FindBugs tool. ³⁾ also requires tool='<tool name>' service message attribute, where <tool name> is one of: dotcover, partcover, ncover or ncover3.

• If not specially noted, the report types support Ant-like wildcards in the path attribute.

• verbose='true' attribute will enable detailed logging into the build log.

• parseOutOfDate='true' attribute will process all the files matching the path. Otherwise, only those updated during the build (is determined by last modification timestamp) are processed.

• whenNoDataPublished=<action> (where <action> is one of the following: info (default), nothing, warning, error) will change output level if no reports matching the path specified were found.

(deprecated, use Build Failure Conditions instead) findBugs, pmd or checkstyle importData messages also take optional errorLimit and warningLimit attributes which specify errors and warnings limits, exceeding which will cause the build failure.

To initiate monitoring several directories or parse several types of the report, send the corresponding service messages one after another.

teamcity-info.xml

It is also possible to have the build script collect information, generate an XML file called teamcity-info.xml in the root build directory. When the build finishes, this file will automatically be uploaded as a build artifact and processed by the TeamCity server.

Please note that this approach can be discontinued in the future TeamCity versions, so service messages approach is recommended instead. In case service messages does not work for you please let us know the details and describe the case via Feedback.

Modifying the Build Status

TeamCity has the ability to change the build status directly from the build script. You can set the status (build failure or success) and change the text of the build status (for example, note the number of failed tests if the test framework is not supported by TeamCity).

Build Script Interaction with TeamCity

It is possible to set the following information for the build:

• Build number — Sets the new number for the finished build. You can reference the TeamCity-provided build number using {build.number}.

• Build status — Change the build status. Supported values are "FAILURE" and "SUCCESS".

• Status text — Modify the text of build status. You can replace the TeamCity-provided status text or add a custom part before or after the standard text. Supported action values are "append", "prepend" and "replace".

Example teamcity-info.xml file:

<build number="1.0.{build.number}"> <statusInfo status="FAILURE"> <!-- or SUCCESS --> <text action="append"> fitnesse: 45</text> <text action="append"> coverage: 54%</text> </statusInfo> </build>

Reporting Custom Statistics

It is possible to provide Customizing Statistics Charts in TeamCity. Your build can provide data for such graphs using teamcity-info.xml file.

provideStatsUsingFileProviding data using the teamcity-info.xml file

This file should be created by the build in the root directory of the build. You can publish multiple statistics (see the details on the data format below) and create separate charts for each set of values.

The teamcity-info.xml file should contain code in the following format (you can combine various data in the teamcity-info.xml file):

<build> <statisticValue key="chart1Key" value="342"/> <statisticValue key="chart2Key" value="53"/> </build>

The key should not be equal to any of Customizing Statistics Charts. The value should be a positive integer value.

The key here relates to the key of valueType tag used when describing the chart.

DescribeGraphsUsingFileDescribing custom charts

See Customizing Statistics Charts page for detailed description.