Prior to TeamCity 9.1, one test could have been reported from within another test.
In the later versions,starting another test finishes the currently started test in the same "flow". To still report tests from within other tests, you will need to specify another flowId in the nested test service messages.
All the other test messages (except for
Currently, the test-related service messages cannot be output with If using the Ant's echo task until flowId attribute is specifiedto output the messages, make sure to include the flowId attribute with the same value in all the messages related to the same test/test suite, as they will not be processed correctly otherwise.
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 must be reported under the same name in every build). Include absolute paths in the reported test names is strongly discouraged.
where all the attributes are required and can have either numeric or textual values
id - (mandatory) limited by 255 characters
name - (mandatory) limited by 255 characters
category - (mandatory) limited by 255 characters. The
category attribute examples are "Style violations", "Calling contracts" etc.
description (mandatory) limited by 4000 characters. The description can also be in html, e.g.
where all the attributes can have either numeric or textual values:
typeId - (mandatory), reference to the
inspectionType.id described above limited by 255 characters
message - (optional) current instance description limited by 4000 characters
file - (mandatory) file path limited by 4000 characters. The path can be absolute or relative to the checkout directory
line - (optional) line of the file, integer
additional attribute - can be any attribute,
SEVERITY is often used here, with one of the following values ( mind the upper case):
TeamCity allows changing the build status text from the build script. Unlike progress messages, this change persists even after a build has finished.
You can also change the build status of a failing build to success.
Prior to TeamCity 7.1, this service message could be used for changing the build status to failed. In the later TeamCity versions, the buildProblem service message is to be used for that.
By using a dedicated service message in your build script, you can dynamically update build parameters of the build right from a build step (the parameters need to be defined in the Parameters section of the build configuration).
The changed build parameters will be available in the build steps following the modifying one. They will also be available as build parameters and can be used in the dependent builds via
%dep.*% parameter references, e.g.
##teamcity[setParameter name='ddd' value='fff']
- Using a service message in a build script directly
- Providing data using the teamcity-info.xml file
To report build statistics using service messages: Specify a '
buildStatisticValue' service message with the following format for each statistics value you want to report: