サービスメッセージ
Service messages are specially constructed pieces of text that pass commands/information about the build from the build script to the TeamCity server.
TeamCity、それらはビルドの標準出力ストリームに書き込まれる必要があり、ビルドステップから出力またはエコーされますによって処理されます。
例:
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 では foo's test として表示されます。以下のエスケープ値の表を参照してください。
文字 | として逃げる |
|---|---|
' (アポストロフィ) | |' |
\n (改行) | | n |
\r (復帰) | | r |
\uNNNN (コード 0xNNNN の Unicode シンボル) | | 0xNNNN |
| （縦線） | || |
[ (左角括弧) | |[ |
] (右角括弧) | |] |
共通プロパティ
どのメッセージでも、オプションの属性 timestamp および flowId をサポートしています。次の例では、<messageName> は特定のサービスメッセージの名前です。
メッセージ作成タイムスタンプ
タイムスタンプの形式は、Java SimpleDateFormat の構文(英語)に従って yyyy-MM-dd'T'HH:mm:ss.SSSZ または yyyy-MM-dd'T'HH:mm:ss.SSS です。
例:
.NET DateTimeOffset(英語) の場合、このようなコード
になります
メッセージ FlowId
flowId は、ビルド内のメッセージフローの一意の識別子です。Flow トラッキングは、たとえば、並行して実行されている個別のプロセスを区別するために必要です。識別子は、個々のビルドのスコープ内で一意である必要がある文字列です。
ほとんどの場合、メッセージフローを開始するために必要な属性は flowId だけです。
ルートフロー内ではなく既存のフロー内のサブフローとしてフローを開始する必要がある場合は、flowStarted パラメーターを追加し、親フロー ID を parent パラメーターとして指定します。指定された親のないフローは、現在のステップのルートフロー内で開始されます。
サブフローを終了するには、flowFinished パラメーターを使用します。親フローを終了すると、すべてのサブフローが自動的に閉じますが、フローの順序を明示的に宣言することをお勧めします。
このカスタムサブフローの順序は、ビルドログの一連のレポートに影響を与え、結果をサブツリーとしてレポートできます。
ビルドログのレポートメッセージ
次の方法でビルドログのメッセージを報告できます。
where:
statusは、NORMAL（デフォルト）、WARNING,FAILURE,ERRORの値を取る場合があります。errorDetailsis used only ifstatusisERROR, in other cases it is ignored.
This message fails the build in case its status isERRORand 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 属性があり、説明を追加することもできます。
ブロックを閉じる：
コンパイルメッセージの報告
where:
compiler_nameは、コンパイルを実行するコンパイラーの任意の名前です（例：javacまたはgroovyc）。現在、ビルドログでブロック名として使用されています。compilationStartedとcompilationFinishedの間で報告されたステータスERRORのメッセージは、コンパイルエラーとして扱われます。
レポートテスト
TeamCity のオンザフライテストレポートを使用するには、テストフレームワークがこの機能を動作させるための専用サポートが必要です（または、XML レポート処理を使用できます）。TeamCity がテストフレームワークをネイティブでサポートしていない場合、サービススクリプトを使用してテスト実行を TeamCity サーバーに報告するようにビルドスクリプトを変更できます。これにより、テスト結果をリアルタイムで表示し、ビルド結果ページのテストタブでテスト情報を利用できるようになります。
サポートされているテストサービスメッセージ
テストスイートのメッセージ : テストスイートは、テストをグループ化するために使用されます。TeamCity は、ビルド結果ページのテストタブやその他の場所に、スイートごとにグループ化されたテストを表示します。
すべての個々のテストメッセージは、同じ name 属性を持つ testSuiteStarted と testSuiteFinished の間に（この順序で）表示されます。
入れ子になったテスト報告
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.
開始 / 停止メッセージをテストします。
testName が実行されたことを示します。 testFailed メッセージが存在しない場合、テストは成功したと見なされます。
duration（オプションの数値整数属性）は、TeamCity UI で報告されるテスト期間をミリ秒単位で設定します。省略した場合、テスト期間はメッセージのタイムスタンプから計算されます。タイムスタンプが欠落している場合 - サーバーでメッセージが受信された実際の時刻から。captureStandardOutput（オプションのブール属性）–trueの場合、testStartedとtestFinishedメッセージ間で受信したすべての標準出力と標準エラーメッセージはテスト出力と見なされます。デフォルト値はfalseです。テスト出力を報告するためにtestStdOutおよびtestStdErrサービスメッセージの使用を想定しています。
test suite + test name のペアがビルド内で一意であることを確認することを強くお勧めします。高度な TeamCity テスト関連機能が機能するためには、テスト名が 1 つのビルドから別のビルドに逸脱してはなりません（1 つのテストがすべてのビルドで同じ名前で報告される必要があります）。報告されたテスト名に絶対パスを含めることは強くお勧めしません。
無視されたテスト:
testName は存在するが、テストフレームワークによって実行されなかった（無視された）ことを示します。例外として、testIgnored メッセージは、一致する testStarted および testFinished メッセージなしで報告できます。
テスト出力:
testStdOut および testStdErr サービスメッセージは、TeamCity UI に表示されるテストの標準およびエラー出力を報告します。テストごとに 1 つの testStdOut メッセージと 1 つの testStdErr メッセージだけがなければなりません。代替方法ですが、信頼性の低い方法は、testStarted メッセージの captureStandardOutput 属性を使用することです。
テスト結果:
testname テストが失敗したことを示します。特定のテスト名に対して表示できる testFailed メッセージは 1 つだけです。
messageには、エラーのテキスト表現が含まれています。detailsには、テスト失敗に関する詳細情報（通常はメッセージと例外スタックトレース）が含まれています。actualおよびexpected属性は、比較の失敗を報告するためにtype='comparisonFailure'と一緒にしか使用できません。IDE でテストを開くときに値が使用されます。
以下はサービスメッセージを使ったテストレポートのより長い例です。
テスト再試行の有効化
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.
テスト名の解釈
完全なテスト名の形式は <suite name>: <package/namespace name>.<class name>.<test method>(<test parameters>) です。<class name> および <test method> には名前にドットを含めることはできません。 <test method> のみが完全なテスト名の必須部分です。
完全なテスト名は、結果のビルド間でテストを比較したり、異なるビルド構成間でテストを一致させるために使用されます。
完全なテスト名の例：
ビルド結果ページのテストタブでは、スイート、パッケージ / 名前空間、クラス、テストごとにグループ化できます。通常、属性値は、テストフレームワークによって報告され、TeamCity がテスト名を正しく解釈できるため提供されます。
上記の形式でテストを解析できない場合、TeamCity は引き続きテストタブのフィルタリング用に完全なテスト名から <suite name> を抽出しようとし、スイートの後のすべてを解析不能なテスト名として扱います。
追加テストデータの報告
testMetadata サービスメッセージを使用して、テストに追加情報を添付することができます。詳細は別のページで入手できます。
.NET コードカバレッジ結果の報告
サービスメッセージを使用して .NET カバレッジ処理を設定できます。詳しくはレポートカバレッジの手動設定のページを参照してください。
報告インスペクション
下記のサービスメッセージを使用して、カスタムツールからインスペクションを TeamCity に報告できます。
他の用途の中でも、インスペクションの数はビルドを失敗させるためのビルドメトリックとして使用できます。
インスペクションタイプ
コード内の特定の警告またはエラー（インスペクションインスタンス）にはそれぞれインスペクションタイプがあります。これは、実施されたインスペクションの一意の説明で、これは
ここで、すべての属性が必須であり、数値またはテキスト値を使用できます。
id–（必須）255 文字に制限されていますname–（必須）255 文字に制限されていますcategory–（必須）255 文字に制限されています。category属性の例は、「スタイル違反」と「呼び出し契約」です。description–（必須）4000 文字に制限されています。説明は HTML でもかまいません。例：
インスペクションインスタンス
特定の不具合、警告、エラーメッセージを報告します。場所、説明、さまざまなオプションおよびカスタム属性が含まれています。
ここで、すべての属性は数値またはテキスト値を持つことができます。
typeId–（必須）、255 文字に制限された上記のinspectionType.idへの参照。message–（オプション）現在のインスタンスの説明は 4000 文字に制限されています。file–（必須）ファイルパスは 4000 文字に制限されています。パスは、チェックアウトディレクトリに対する絶対パスまたは相対パスにすることができます。line–（オプション）ファイルの行、整数。additional attribute- 任意の属性を指定できます。ここでは、SEVERITYがよく使用され、次の値のいずれか（大文字に注意してください）：INFO,ERROR,WARNING,WEAK WARNING
例:
ビルドの進行中にアーティファクトを公開する
ビルドの実行中に、アーティファクトがビルドされた直後に、ビルドアーティファクトを公開することができます。
これを行うには、次の行を出力する必要があります。
<path> は、ビルド設定のアーティファクト仕様の構築と同じ規則に従う必要があります。 <path> に一致するファイルがアップロードされ、実行中のビルドのアーティファクトとして表示されます。
すべてのファイルの準備が整い、ファイルが読み取り用にロックされていないときにメッセージが表示されます。
アーティファクトはバックグラウンドでアップロードされるため、時間がかかる場合があります。一致するファイルがビルドの最後まで削除されていないことを確認してください（たとえば、次回のビルド開始時にクリーンアップされるディレクトリ、一時ディレクトリ、またはビルド後に Swabra を使用してクリーンアップすることができます）。
ビルド構成設定で指定されたアーティファクトは、通常どおりに公開されます。
ステップ間で NuGet パッケージを渡す
NuGet パッケージを公開してから、そのコンテンツを 1 つのビルド内で使用する必要がある場合は、ビルドの終了時ではなく、時間どおりに公開され、インデックスが作成されることを保証する必要があります。
このために、NuGet パブリッシュランナーを使用するか、代わりに任意のステップで ##teamcity[publishNuGetPackage] サービスメッセージを送信できます。これにより、NuGet パッケージは、現在のステップの最後に構成済みのすべての NuGet フィードで公開され、次のビルドステップで使用できるようになります。
ビルドの進行状況を報告する
特別な進行メッセージを使用して、ビルドスクリプト内の長時間実行されるパーツをマークできます。これらのメッセージは、対応するビルドのプロジェクトのダッシュボードとビルド結果ページに表示されます。
単一の進捗メッセージを記録するには、次のようにします。
この進行メッセージは、別の進行メッセージが表示されるまで、または次のターゲットが起動するまで表示されます（Ant ビルドの場合）。
ビルドの一部だけの進行状況メッセージを表示したい場合は、次のようにします。
ビルド問題の報告
ビルドスクリプトから直接ビルドを失敗させるには、ビルドの問題を報告する必要があります。ビルドの問題は、ビルドステータステキストに影響します。それらはビルド結果ページに表示されます。ビルドにビルドの問題を追加するには、次を使用します。
where:
description（必須）：ビルドの問題を説明する人間が読めるプレーンテキスト。デフォルトでは、descriptionはビルドステータステキストとビルドの問題のリストに表示されます。テキストは 4000 シンボルに制限されており、制限を超えると切り捨てられます。identity（オプション）：固有の問題 ID。異なる問題には異なるアイデンティティ、同じ問題–同じアイデンティティが必要です。たとえば、同じコンパイルエラーが発生した場合など、同じ問題がビルド全体で発生することはありません。60 文字までの有効な Java ID である必要があります。省略すると、identityはdescriptionテキストに基づいて計算されます。
ビルドステータスの報告
TeamCity では、ビルドスクリプトからビルドステータステキストを変更できます。進捗メッセージとは異なり、この変更はビルドが終了した後も持続します。
失敗したビルドのビルドステータスを SUCCESS に変更することもできます。
ステータスを設定したり、ビルドステータスのテキストを変更したりするには（たとえば、テストフレームワークが TeamCity でサポートされていない場合は失敗したテストの数を書き留めます）、次の形式の buildStatus メッセージを使用します。
where:
status(optional): use theSUCCESSvalue to change the build status to Success.text（必須）：新しいビルドステータステキストを設定します。
オプションで、テキストは{build.status.text}置換パターンを使用できます。これは、合格したテストカウント、コンパイルメッセージなどを使用して TeamCity によって自動的に計算されたステータスを表します。
ステータスセットはビルドの実行中に表示され、最終的なビルド結果にも影響します。
ビルド番号の報告
カスタムビルド番号を直接設定するには、次の形式で buildNumber メッセージを指定してください。
<new build number> 値では、{build.number} 置換を使用して、TeamCity によって自動的に生成された現在のビルド番号を使用できます。例：
ビルドパラメーターを追加または変更する
ビルドスクリプトで専用のサービスメッセージを使用することにより、ビルドステップからビルドのビルドパラメーターを動的に更新できます（パラメーターはビルド構成のパラメーターセクションで定義する必要があります）。変更されたビルドパラメーターは、変更後のビルドステップで使用できます。これらはビルドパラメーターとしても利用可能であり、 %dep.*% parameter references を介して依存ビルドで使用できます。例：
ビルドパラメーターの名前を指定するときは、プレフィックスに注意してください。
システムプロパティの
system環境変数用の
env構成パラメーターのプレフィックスはありません。
ビルドパラメーターとその接頭辞についてのさらに読み込む。
ビルド統計の報告
TeamCity では、統計データをレポートし、そのデータに基づいてチャートを表示するようにビルドスクリプトを設定することができます。Web UI でチャートを表示するためのガイドについては、統計チャートのカスタマイズページを参照してください。このセクションでは、サービススクリプトを介してビルドスクリプトから統計データを報告する方法について説明します。ビルド統計値は、2 つの方法で公開できます。
ビルドスクリプトでサービスメッセージを直接使用する
teamcity-info.xml ファイルを使用してデータを提供する
サービスメッセージを使用してビルド統計をレポートするには：レポートする統計値ごとに、次の形式でbuildStatisticValueサービスメッセージを指定します。
where
keyは、事前定義されたキーのいずれとも等しくてはなりません。valueは、最大 13 桁の正 / 負の整数でなければなりません。小数点以下 6 桁までの浮動小数点値もサポートされています。
サービスメッセージ処理の無効化
何らかの理由で出力内のサービスメッセージの検索を無効にする必要がある場合は、メッセージでサービスメッセージの検索を無効にすることができます。
これら 2 つの間に表示されるメッセージは、サービスメッセージとして解析されず、事実上無視されます。サーバー側のサービスメッセージの処理では、サービスメッセージの有効化 / 無効化も flowId 属性をサポートし、同じ flowId のメッセージのみを無視します。
XML レポートのインポート
UI ビルド機能に加えて、importData サービスメッセージを使用して、ビルドスクリプト内から XML レポートを設定できます。また、メッセージは以前に収集されたコードカバレッジとコードインスペクション / 重複レポートのインポートをサポートします。
サービスメッセージの形式は次のとおりです。
typeID は次のいずれかになります（XML レポート処理も参照）。
typeID | 説明 |
|---|---|
テストフレームワーク | |
| JUnit Ant タスク XML レポート |
| Maven Surefire XML レポート |
| NUnit コンソールの XML レポート |
| MSTest XML レポート |
| VSTest XML レポート |
| Google Test XML レポート |
コード検査 | |
| TeamCity 2017.1 以降、IntelliJ IDEA、インスペクションの結果 |
| チェックスタイルインスペクション XML レポート |
| FindBugs インスペクション XML レポート |
| JSLint XML レポート |
| ReSharper |
| FxCop インスペクション XML レポート |
| PMD インスペクション XML レポート |
コードの重複 | |
| PMD コピー / 貼り付け検出機能（CPD）XML レポート |
| ReSharper |
コードカバレッジ | |
| dotcover、partcover、ncover、または ncover3 によって生成された XML レポート |
ノート:
path属性の特定のファイルのみをサポートします。インストールされた FindBugs ツールのホームディレクトリを指すように指定された
findBugsHome属性も必要です。<tool name>がdotcover,partcover,ncoverまたはncover3のいずれかであるtool='<tool name>'サービスメッセージ属性も必要です。
特記しない限り、レポートタイプは path 属性で Ant のようなワイルドカードをサポートします。
verbose='true'属性はビルドログへの詳細なログインを可能にします。parseOutOfDate='true'属性は、パスに一致するすべてのファイルを処理します。デフォルトでは、ビルド中に更新されたもの（最後の修正タイムスタンプによって決定されたもの）のみが処理されます。一致しないレポートが見つかった場合は、「レポートが期限切れとしてスキップされました」というメッセージがビルドログに表示されます。whenNoDataPublished=<action>（<action>は次のいずれかです：info（デフォルト）、nothing,warning,error）は、指定されたパスに一致するレポートが見つからなかった場合、出力レベルを変更します。（代わりに非推奨、ビルド失敗条件を使用）
findBugs,pmdまたはcheckstyleimportData メッセージは、エラーと警告の制限を指定するオプションのerrorLimitおよびwarningLimit属性も取り、これを超えると、ビルドが失敗します。
複数のディレクトリの監視を開始したり、複数の種類のレポートを解析したりするには、対応するサービスメッセージを次々に送信します。
サービスメッセージによるビルドのキャンセル
スクリプトからビルドをキャンセルする必要がある場合、たとえば、ビルドが環境のせいで正常に続行できない場合、またはサブプロセスからビルドをキャンセルする必要がある場合は、次のサービスメッセージを使用できます。
必要に応じて、キャンセルした後でビルドをキューに再度追加できます。
TeamCity サービスメッセージ経由のライブラリレポート結果
JetBrains および外部ソースからのいくつかのプラットフォーム固有のライブラリは、TeamCity サービスメッセージを介して結果を報告できます。
サービスメッセージ .NET ライブラリ(英語)– .NET library for generating (and parsing) TeamCity service messages from .NET applications. See a related blog post(英語).
Jasmine 2.0 TeamCity レポーター(英語)– Jasmine 2.0 レポーターから TeamCity サービスメッセージを送信するためのサポート
Perl TAP フォーマッター(英語)– TAP メッセージを TeamCity サービスメッセージに変換する Perl のフォーマッタ
PHPUnit 5.0(英語) –テスト用の TeamCity サービスメッセージをサポートします。以前の PHPUnit バージョンでは、次の外部ライブラリを使用できます。PHPUnit リスナー 1(英語)、PHPUnit リスナー 2(英語) – PHPUnit の
suite.xmlを介してプラグインして、テスト用の TeamCity サービスメッセージを生成できるリスナー。Python への Python 単体テストレポート TeamCity(英語) –ユニットテストをサービスメッセージを介して TeamCity サーバーに自動的に報告するパッケージ（TeamCity で実行され、テストコードがそれを使用するように適合している場合）。
Mocha(英語) – on-the-fly reporting via service messages for Mocha JavaScript testing framework. See the related post(英語) with instructions.
Karma(英語) – TeamCity サービスメッセージを使用して TeamCity にテストの進行状況を報告する JavaScript テストツールのサポート
関連ページ：
ビルドの失敗条件
TeamCity では、ビルドが失敗としてマークされる条件を変更できます。これらのビルドの失敗条件は、ビルド設定| 失敗条件で調整できます。ビルドに十分なディスク領域を解放できない場合にビルドを失敗させるには、空きディスク容量ビルド機能を参照してください。一般的なビルド失敗条件 ：一般的な障害状態ブ...
テストメタデータの報告
TeamCity でのテスト実行は、テストステータス、実行時間、出力を補完するいくつかの追加情報（メタデータ）に関連付けることができます。この情報は、追加のログ、スクリーンショット、数値、タグなどを提供するために使用できます。これで、サービスメッセージを使用して、TeamCity でこの種の追加のテ...