TeamCity 2020.2 ヘルプ

サービスメッセージ

Service messages are specially constructed pieces of text that pass commands/information about the build from the build script to the TeamCity server.

TeamCity、それらはビルドの標準出力ストリームに書き込まれる必要があり、ビルドステップから出力またはエコーされますによって処理されます。

例:

echo ##teamcity[<messageName> 'value']
echo "##teamcity[<messageName> 'value']"
Write-Host "##teamcity[<messageName> 'value']"

1 つのサービスメッセージに改行文字を含めることはできません。複数行にまたがることはできません。

サービスメッセージフォーマット

サービスメッセージは 2 つのフォーマットをサポートします。

  • 単一属性メッセージ

    ##teamcity[<messageName> 'value']
  • 複数属性メッセージ

    ##teamcity[<messageName> name1='value1' name2='value2']

    複数属性メッセージは、より正式には次のように説明できます。

    ##teamcity[messageNameWSPpropertyNameOWSP=OWSP'value'WSPpropertyName_IDOWSP=OWSP'value'...OWSP]

where:

  • messageName はメッセージの名前です。有効な Java ID でなければなりません(文字で始まる英数字と - のみ)。

  • propertyName は、メッセージ属性の名前です。有効な Java ID でなければなりません。

  • value は属性の値です。エスケープされた値でなければなりません。

  • WSP は必須の空白です:スペースまたはタブ文字(\t)。

  • OWSP はオプションの空白です。

  • ... は、任意の数の WSPpropertyNameOWSP=OWSP'value' ブロックです。

エスケープ値

エスケープされた値の場合、TeamCity はエスケープ文字として垂直バー | を使用します。TeamCity サーバーによって特定の特殊文字が適切に解釈されるようにするには、それらの前に垂直バーが必要です。例:次のメッセージ:

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

TeamCity では foo's test として表示されます。以下のエスケープ値の表を参照してください。

文字

として逃げる

' (アポストロフィ)

|'

\n (改行)

| n

\r (復帰)

| r

\uNNNN (コード 0xNNNN の Unicode シンボル)

| 0xNNNN

| (縦線)

||

[ (左角括弧)

|[

] (右角括弧)

|]

共通プロパティ

どのメッセージでも、オプションの属性 timestamp および flowId をサポートしています。次の例では、<messageName> は特定のサービスメッセージの名前です。

メッセージ作成タイムスタンプ

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

タイムスタンプの形式は、Java SimpleDateFormat の構文(英語)に従って yyyy-MM-dd'T'HH:mm:ss.SSSZ または yyyy-MM-dd'T'HH:mm:ss.SSS です。

例:

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

.NET DateTimeOffset(英語) の場合、このようなコード

var date = DateTimeOffset.Now; var timestamp = $"{date:yyyy-MM-dd'T'HH:mm:ss.fff}{date.Offset.Ticks:+;-;}{date.Offset:hhmm}";

になります

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

メッセージ FlowId

flowId は、ビルド内のメッセージフローの一意の識別子です。Flow トラッキングは、たとえば、並行して実行されている個別のプロセスを区別するために必要です。識別子は、個々のビルドのスコープ内で一意である必要がある文字列です。

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

ほとんどの場合、メッセージフローを開始するために必要な属性は flowId だけです。

ルートフロー内ではなく既存のフロー内のサブフローとしてフローを開始する必要がある場合は、flowStarted パラメーターを追加し、親フロー ID を parent パラメーターとして指定します。指定された親のないフローは、現在のステップのルートフロー内で開始されます。
サブフローを終了するには、flowFinished パラメーターを使用します。親フローを終了すると、すべてのサブフローが自動的に閉じますが、フローの順序を明示的に宣言することをお勧めします。

##teamcity[<messageName> flowStarted flowId='MainFlow' ...] ##teamcity[<messageName> flowStarted flowId='SubFlow1' parent='MainFlow' ...] ##teamcity[<messageName> flowFinished flowId='SubFlow1' ...] ##teamcity[<messageName> flowStarted flowId='SubFlow2' parent='MainFlow' ...] ##teamcity[<messageName> flowFinished flowId='SubFlow2' ...] ##teamcity[<messageName> flowFinished flowId='MainFlow' ...]

このカスタムサブフローの順序は、ビルドログの一連のレポートに影響を与え、結果をサブツリーとしてレポートできます。

ビルドログのレポートメッセージ

次の方法でビルドログのメッセージを報告できます。

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

where:

  • status は、NORMAL (デフォルト)、WARNING , FAILURE , ERROR の値を取る場合があります。

  • errorDetails 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 the "Fail build if an error message is logged by build runner" box is checked on the ビルドの失敗条件 page of the build configuration. For example:

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

サービスブロックメッセージ

ブロックはビルドログ内のいくつかのメッセージをグループ化するために使用されます。

ブロックオープニング:

blockOpened システムメッセージには name 属性があり、説明を追加することもできます。

##teamcity[blockOpened name='<blockName>' description='<this is the description of blockName>']

ブロックを閉じる:

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

コンパイルメッセージの報告

##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 は、コンパイルを実行するコンパイラーの任意の名前です(例: javac または groovyc)。現在、ビルドログでブロック名として使用されています。

  • compilationStartedcompilationFinished の間で報告されたステータス ERROR のメッセージは、コンパイルエラーとして扱われます。

レポートテスト

TeamCity のオンザフライテストレポートを使用するには、テストフレームワークがこの機能を動作させるための専用サポートが必要です(または、XML レポート処理を使用できます)。TeamCity がテストフレームワークをネイティブでサポートしていない場合、サービススクリプトを使用してテスト実行を TeamCity サーバーに報告するようにビルドスクリプトを変更できます。これにより、テスト結果をリアルタイムで表示し、ビルド結果ページのテストタブでテスト情報を利用できるようになります。

サポートされているテストサービスメッセージ

テストスイートのメッセージ : テストスイートは、テストをグループ化するために使用されます。TeamCity は、ビルド結果ページのテストタブやその他の場所に、スイートごとにグループ化されたテストを表示します。

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

すべての個々のテストメッセージは、同じ name 属性を持つ testSuiteStartedtestSuiteFinished の間に(この順序で)表示されます。

入れ子になったテスト報告

Prior to TeamCity 9.1, one test could have been reported from within another test (see the example at the end of this section). 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.

開始 / 停止メッセージをテストします。

##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>']

testName が実行されたことを示します。 testFailed メッセージが存在しない場合、テストは成功したと見なされます。

  • duration (オプションの数値整数属性)は、TeamCity UI で報告されるテスト期間をミリ秒単位で設定します。省略した場合、テスト期間はメッセージのタイムスタンプから計算されます。タイムスタンプが欠落している場合 - サーバーでメッセージが受信された実際の時刻から。

  • captureStandardOutput (オプションのブール属性)– true の場合、testStartedtestFinished メッセージ間で受信したすべての標準出力と標準エラーメッセージはテスト出力と見なされます。デフォルト値は false です。テスト出力を報告するために testStdOut および testStdErr サービスメッセージの使用を想定しています。

test suite + test name のペアがビルド内で一意であることを確認することを強くお勧めします。高度な TeamCity テスト関連機能が機能するためには、テスト名が 1 つのビルドから別のビルドに逸脱してはなりません(1 つのテストがすべてのビルドで同じ名前で報告される必要があります)。報告されたテスト名に絶対パスを含めることは強くお勧めしません

無視されたテスト:

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

testName は存在するが、テストフレームワークによって実行されなかった(無視された)ことを示します。例外として、testIgnored メッセージは、一致する testStarted および testFinished メッセージなしで報告できます。

テスト出力:

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

testStdOut および testStdErr サービスメッセージは、TeamCity UI に表示されるテストの標準およびエラー出力を報告します。テストごとに 1 つの testStdOut メッセージと 1 つの testStdErr メッセージだけがなければなりません。代替方法ですが、信頼性の低い方法は、testStarted メッセージの captureStandardOutput 属性を使用することです。

テスト結果:

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

testname テストが失敗したことを示します。特定のテスト名に対して表示できる testFailed メッセージは 1 つだけです。

  • message には、エラーのテキスト表現が含まれています。

  • details には、テスト失敗に関する詳細情報(通常はメッセージと例外スタックトレース)が含まれています。

  • actual および expected 属性は、比較の失敗を報告するために type='comparisonFailure' と一緒にしか使用できません。IDE でテストを開くときに値が使用されます。

以下はサービスメッセージを使ったテストレポートのより長い例です。

##teamcity[testSuiteStarted name='suiteName'] ##teamcity[testSuiteStarted name='nestedSuiteName'] ##teamcity[testStarted name='package_or_namespace.ClassName.TestName'] ##teamcity[testFailed name='package_or_namespace.ClassName.TestName' message='The number must 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='nestedSuiteName'] ##teamcity[testSuiteFinished name='suiteName']

テスト再試行の有効化

You can enable the support of test retry for a build configuration. With this option enabled, the successful run of a test will mute its previous failure, which means that TeamCity will mute a test if it fails and then succeeds within the same build.
Such tests will not affect the build status.

##teamcity[testRetrySupport enabled=’true’]

テスト名の解釈

完全なテスト名の形式は <suite name>: <package/namespace name>.<class name>.<test method>(<test parameters>) です。<class name> および <test method> には名前にドットを含めることはできません。 <test method> のみが完全なテスト名の必須部分です。

完全なテスト名は、結果のビルド間でテストを比較したり、異なるビルド構成間でテストを一致させるために使用されます。

完全なテスト名の例:

Integration Tests: Backend: org.jetbrains.teamcity.LoginPageController.testBadPassword("incorrect password", false) // in the example above, // suite name = "Integration Tests: Backend" // package = org.jetbrains.teamcity // class name = LoginPageController // test method = testBadPassword // test parameters = ("incorrect password", false)

ビルド結果ページのテストタブでは、スイート、パッケージ / 名前空間、クラス、テストごとにグループ化できます。通常、属性値は、テストフレームワークによって報告され、TeamCity がテスト名を正しく解釈できるため提供されます。

上記の形式でテストを解析できない場合、TeamCity は引き続きテストタブのフィルタリング用に完全なテスト名から <suite name> を抽出しようとし、スイートの後のすべてを解析不能なテスト名として扱います。

追加テストデータの報告

testMetadata サービスメッセージを使用して、テストに追加情報を添付することができます。詳細は別のページで入手できます。

.NET コードカバレッジ結果の報告

サービスメッセージを使用して .NET カバレッジ処理を設定できます。詳しくはレポートカバレッジの手動設定のページを参照してください。

報告インスペクション

下記のサービスメッセージを使用して、カスタムツールからインスペクションを TeamCity に報告できます。

他の用途の中でも、インスペクションの数はビルドを失敗させるためのビルドメトリックとして使用できます。

インスペクションタイプ

コード内の特定の警告またはエラー(インスペクションインスタンス)にはそれぞれインスペクションタイプがあります。これは、実施されたインスペクションの一意の説明で、これは

##teamcity[inspectionType id='<id>' name='<name>' description='<description>' category='<category>']

ここで、すべての属性が必須であり、数値またはテキスト値を使用できます。

  • id –(必須)255 文字に制限されています

  • name –(必須)255 文字に制限されています

  • category –(必須)255 文字に制限されています。 category 属性の例は、「スタイル違反」と「呼び出し契約」です。

  • description –(必須)4000 文字に制限されています。説明は HTML でもかまいません。例:

<html> <body> Reports unnecessary local variables, which add nothing to the comprehensibility of a method. Variables caught include local variables which are immediately returned, local variables that are immediately assigned to another variable and then not used, and local variables which always have the same value as another local variable or parameter. <!-- tooltip end --> <p> Use the first checkbox below to have this inspection ignore variables which are immediately returned or thrown. Some coding styles suggest using such variables for clarity and ease of debugging. </p> <p> Use the second checkbox below to have this inspection ignore variables which are annotated. </p> </body> </html>

インスペクションインスタンス

特定の不具合、警告、エラーメッセージを報告します。場所、説明、さまざまなオプションおよびカスタム属性が含まれています。

##teamcity[inspection typeId='<inspection type identity>' message='<instance description>' file='<file path>' line='<line>' additional attribute='<additional attribute>']

ここで、すべての属性は数値またはテキスト値を持つことができます。

  • typeId –(必須)、255 文字に制限された上記inspectionType.id への参照。

  • message –(オプション)現在のインスタンスの説明は 4000 文字に制限されています。

  • file –(必須)ファイルパスは 4000 文字に制限されています。パスは、チェックアウトディレクトリに対する絶対パスまたは相対パスにすることができます。

  • line –(オプション)ファイルの行、整数。

  • additional attribute- 任意の属性を指定できます。ここでは、SEVERITY がよく使用され、次の値のいずれか(大文字に注意してください): INFO , ERROR , WARNING , WEAK WARNING

例:

##teamcity[inspectionType id='UnnecessaryLocalVariable' name='Redundant local variable' description='<html><body>Reports unnecessary local variables...</body> </html>' category='Data flow issues'] ##teamcity[inspection typeId='UnnecessaryLocalVariable' message='Local variable <code>i</code> is redundant' file='src/Test.java' line='19' SEVERITY='WARNING']

ビルドの進行中にアーティファクトを公開する

ビルドの実行中に、アーティファクトがビルドされた直後に、ビルドアーティファクトを公開することができます。

これを行うには、次の行を出力する必要があります。

##teamcity[publishArtifacts '<path>']

<path> は、ビルド設定アーティファクト仕様の構築と同じ規則に従う必要があります。 <path> に一致するファイルがアップロードされ、実行中のビルドのアーティファクトとして表示されます。

すべてのファイルの準備が整い、ファイルが読み取り用にロックされていないときにメッセージが表示されます。

アーティファクトはバックグラウンドでアップロードされるため、時間がかかる場合があります。一致するファイルがビルドの最後まで削除されていないことを確認してください(たとえば、次回のビルド開始時にクリーンアップされるディレクトリ一時ディレクトリ、またはビルド後に Swabra を使用してクリーンアップすることができます)。

ビルド構成設定で指定されたアーティファクトは、通常どおりに公開されます。

ステップ間で NuGet パッケージを渡す

NuGet パッケージを公開してから、そのコンテンツを 1 つのビルド内で使用する必要がある場合は、ビルドの終了時ではなく、時間どおりに公開され、インデックスが作成されることを保証する必要があります。
このために、NuGet パブリッシュランナーを使用するか、代わりに任意のステップで ##teamcity[publishNuGetPackage] サービスメッセージを送信できます。これにより、NuGet パッケージは、現在のステップの最後に構成済みのすべての NuGet フィードで公開され、次のビルドステップで使用できるようになります。

ビルドの進行状況を報告する

特別な進行メッセージを使用して、ビルドスクリプト内の長時間実行されるパーツをマークできます。これらのメッセージは、対応するビルドのプロジェクトのダッシュボードとビルド結果ページに表示されます。

単一の進捗メッセージを記録するには、次のようにします。

##teamcity[progressMessage '<message>']

この進行メッセージは、別の進行メッセージが表示されるまで、または次のターゲットが起動するまで表示されます(Ant ビルドの場合)。

ビルドの一部だけの進行状況メッセージを表示したい場合は、次のようにします。

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

ビルド問題の報告

ビルドスクリプトから直接ビルドを失敗させるには、ビルドの問題を報告する必要があります。ビルドの問題は、ビルドステータステキストに影響します。それらはビルド結果ページに表示されます。ビルドにビルドの問題を追加するには、次を使用します。

##teamcity[buildProblem description='<description>' identity='<identity>']

where:

  • description (必須):ビルドの問題を説明する人間が読めるプレーンテキスト。デフォルトでは、description はビルドステータステキストとビルドの問題のリストに表示されます。テキストは 4000 シンボルに制限されており、制限を超えると切り捨てられます。

  • identity (オプション):固有の問題 ID。異なる問題には異なるアイデンティティ、同じ問題–同じアイデンティティが必要です。たとえば、同じコンパイルエラーが発生した場合など、同じ問題がビルド全体で発生することはありません。60 文字までの有効な Java ID である必要があります。省略すると、identitydescription テキストに基づいて計算されます。

ビルドステータスの報告

TeamCity では、ビルドスクリプトからビルドステータステキストを変更できます。進捗メッセージとは異なり、この変更はビルドが終了した後も持続します。
失敗したビルドのビルドステータスを SUCCESS に変更することもできます。

ステータスを設定したり、ビルドステータスのテキストを変更したりするには(たとえば、テストフレームワークが TeamCity でサポートされていない場合は失敗したテストの数を書き留めます)、次の形式の buildStatus メッセージを使用します。

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

where:

  • status (optional): use the SUCCESS value to change the build status to Success.

  • text (必須):新しいビルドステータステキストを設定します。
    オプションで、テキストは {build.status.text} 置換パターンを使用できます。これは、合格したテストカウント、コンパイルメッセージなどを使用して TeamCity によって自動的に計算されたステータスを表します。
    ステータスセットはビルドの実行中に表示され、最終的なビルド結果にも影響します。

ビルド番号の報告

カスタムビルド番号を直接設定するには、次の形式で buildNumber メッセージを指定してください。

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

<new build number> 値では、{build.number} 置換を使用して、TeamCity によって自動的に生成された現在のビルド番号を使用できます。例:

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

ビルドパラメーターを追加または変更する

ビルドスクリプトで専用のサービスメッセージを使用することにより、ビルドステップからビルドのビルドパラメーターを動的に更新できます(パラメーターはビルド構成のパラメーターセクションで定義する必要があります)。変更されたビルドパラメーターは、変更後のビルドステップで使用できます。これらはビルドパラメーターとしても利用可能であり、 %dep.*% parameter references を介して依存ビルドで使用できます。例:

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

ビルドパラメーターの名前を指定するときは、プレフィックスに注意してください。

  • システムプロパティの system

  • 環境変数用の env

  • 構成パラメーターのプレフィックスはありません。

ビルドパラメーターとその接頭辞についてのさらに読み込む

ビルド統計の報告

TeamCity では、統計データをレポートし、そのデータに基づいてチャートを表示するようにビルドスクリプトを設定することができます。Web UI でチャートを表示するためのガイドについては、統計チャートのカスタマイズページを参照してください。このセクションでは、サービススクリプトを介してビルドスクリプトから統計データを報告する方法について説明します。ビルド統計値は、2 つの方法で公開できます。

  • ビルドスクリプトでサービスメッセージを直接使用する

  • teamcity-info.xml ファイルを使用してデータを提供する
    サービスメッセージを使用してビルド統計をレポートするには:レポートする統計値ごとに、次の形式で buildStatisticValue サービスメッセージを指定します。

##teamcity[buildStatisticValue key='<valueTypeKey>' value='<value>']

where

  • key は、事前定義されたキーのいずれとも等しくてはなりません。

  • value は、最大 13 桁の正 / 負の整数でなければなりません。小数点以下 6 桁までの浮動小数点値もサポートされています。

サービスメッセージ処理の無効化

何らかの理由で出力内のサービスメッセージの検索を無効にする必要がある場合は、メッセージでサービスメッセージの検索を無効にすることができます。

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

これら 2 つの間に表示されるメッセージは、サービスメッセージとして解析されず、事実上無視されます。サーバー側のサービスメッセージの処理では、サービスメッセージの有効化 / 無効化も flowId 属性をサポートし、同じ flowId のメッセージのみを無視します。

XML レポートのインポート

UI ビルド機能に加えて、importData サービスメッセージを使用して、ビルドスクリプト内から XML レポートを設定できます。また、メッセージは以前に収集されたコードカバレッジとコードインスペクション / 重複レポートのインポートをサポートします。

サービスメッセージの形式は次のとおりです。

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

typeID は次のいずれかになります(XML レポート処理も参照)。

typeID

説明

テストフレームワーク

junit

JUnit Ant タスク XML レポート

surefire

Maven Surefire XML レポート

nunit

NUnit コンソールの XML レポート

mstest

MSTest XML レポート

vstest

VSTest XML レポート

gtest

Google Test XML レポート

コード検査

intellij-inspections

TeamCity 2017.1 以降、IntelliJ IDEA、インスペクションの結果

checkstyle

チェックスタイルインスペクション XML レポート

findBugs 2)

FindBugs インスペクション XML レポート

jslint

JSLint XML レポート

ReSharperInspectCode 1)

ReSharper inspectCode.exe XML レポート

FxCop 1

FxCop インスペクション XML レポート

pmd

PMD インスペクション XML レポート

コードの重複

pmdCpd

PMD コピー / 貼り付け検出機能(CPD)XML レポート

DotNetDupFinder 1)

ReSharper dupfinder.exe XML レポート

コードカバレッジ

dotNetCoverage 1) 3)

dotcover、partcover、ncover、または ncover3 によって生成された XML レポート

ノート:

  1. path 属性の特定のファイルのみをサポートします。

  2. インストールされた FindBugs ツールのホームディレクトリを指すように指定された findBugsHome 属性も必要です。

  3. <tool name>dotcover , partcover , ncover または ncover3 のいずれかである tool='<tool name>' サービスメッセージ属性も必要です。

特記しない限り、レポートタイプは path 属性で Ant のようなワイルドカードをサポートします。

  • verbose='true' 属性はビルドログへの詳細なログインを可能にします。

  • parseOutOfDate='true' 属性は、パスに一致するすべてのファイルを処理します。デフォルトでは、ビルド中に更新されたもの(最後の修正タイムスタンプによって決定されたもの)のみが処理されます。一致しないレポートが見つかった場合は、「レポートが期限切れとしてスキップされました」というメッセージがビルドログに表示されます。

  • whenNoDataPublished=<action><action> は次のいずれかです: info (デフォルト)、nothing , warning , error)は、指定されたパスに一致するレポートが見つからなかった場合、出力レベルを変更します。

  • (代わりに非推奨、ビルド失敗条件を使用
    findBugs , pmd または checkstyle importData メッセージは、エラーと警告の制限を指定するオプションの errorLimit および warningLimit 属性も取り、これを超えると、ビルドが失敗します。

複数のディレクトリの監視を開始したり、複数の種類のレポートを解析したりするには、対応するサービスメッセージを次々に送信します。

サービスメッセージによるビルドのキャンセル

スクリプトからビルドをキャンセルする必要がある場合、たとえば、ビルドが環境のせいで正常に続行できない場合、またはサブプロセスからビルドをキャンセルする必要がある場合は、次のサービスメッセージを使用できます。

echo "##teamcity[buildStop comment='canceling comment' readdToQueue='true']"

必要に応じて、キャンセルした後でビルドをキューに再度追加できます。

TeamCity サービスメッセージ経由のライブラリレポート結果

JetBrains および外部ソースからのいくつかのプラットフォーム固有のライブラリは、TeamCity サービスメッセージを介して結果を報告できます。