サービスメッセージ
サービスメッセージは、ビルドスクリプトから TeamCity サーバーにビルドに関するコマンド / 情報を渡す特別に作成されたテキストです。
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
errorDetails
は、status
がERROR
の場合にのみ使用され、それ以外の場合は無視されます。
このメッセージは、ステータスがERROR
の場合にビルドに失敗し、ビルド構成のビルドの失敗条件ページでエラーメッセージがビルドランナーによってログに記録された場合にビルドに失敗するチェックボックスがオンになっています。例:##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
の間に(この順序で)表示されます。
入れ子になったテスト報告
別のテストを開始すると、現在開始されているテストが同じフローで終了します。他のテスト内からテストをレポートするには、ネストされたテストサービスメッセージで別の flowId
を指定する必要があります。
開始 / 停止メッセージをテストします。
testName
が実行されたことを示します。 testFailed
メッセージが存在しない場合、テストは成功したと見なされます。
duration
(オプションの数値整数属性)は、TeamCity UI で報告されるテスト期間をミリ秒単位で設定します。省略した場合、テスト期間はメッセージのタイムスタンプから計算されます。タイムスタンプが欠落している場合 — サーバーでメッセージが実際に受信された時刻から。captureStandardOutput
(オプションのブール属性) —true
の場合、testStarted
メッセージとtestFinished
メッセージの間で受信されたすべての標準出力および標準エラーメッセージはテスト出力と見なされます。デフォルト値はfalse
です。テスト出力を報告するためにtestStdOut
およびtestStdErr
サービスメッセージの使用を想定しています。
test suite
+ test name
のペアがビルド内で一意であることを確認することを強くお勧めします。高度な TeamCity テスト関連機能を機能させるには、テスト名をビルドごとに逸脱させないでください(すべてのビルドで単一のテストを同じ名前で報告する必要があります)。報告されたテスト名に絶対パスを含めることは強くお勧めしません。
無視されたテスト:
testName
は存在するが、テストフレームワークによって実行されなかった(無視された)ことを示します。例外として、testIgnored
メッセージは、一致する testStarted
および testFinished
メッセージなしで報告できます。
テスト出力:
testStdOut
および testStdErr
サービスメッセージは、TeamCity UI に表示されるテストの標準およびエラー出力を報告します。テストごとに 1 つの testStdOut
メッセージと 1 つの testStdErr
メッセージだけがなければなりません。代替方法ですが、信頼性の低い方法は、testStarted
メッセージの captureStandardOutput
属性を使用することです。
テスト結果:
testname
テストが失敗したことを示します。特定のテスト名に対して表示できる testFailed
メッセージは 1 つだけです。
message
には、エラーのテキスト表現が含まれています。details
には、テスト失敗に関する詳細情報(通常はメッセージと例外スタックトレース)が含まれています。actual
およびexpected
属性は、比較の失敗を報告するためにtype='comparisonFailure'
と一緒にしか使用できません。IDE でテストを開くときに値が使用されます。
以下はサービスメッセージを使ったテストレポートのより長い例です。
テスト再試行の有効化
ビルド構成のテスト再試行のサポートを有効にできます。このオプションを有効にすると、テストが正常に実行されると、以前の失敗がミュートされます。つまり、TeamCity は、失敗した場合にテストをミュートし、同じビルド内で成功します。
このようなテストは、ビルドステータスには影響しません。
テスト名の解釈
完全なテスト名の形式は <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。異なる問題は異なる ID、同じ問題を持っている必要があります。同じ ID。同じ問題、たとえば同じコンパイルエラーが発生した場合、ビルド全体で変更されるべきではありません。60 文字までの有効な JavaID である必要があります。省略した場合、identity
はdescription
テキストに基づいて計算されます。
ビルドステータスの報告
TeamCity を使用すると、ビルドスクリプトからビルドステータステキストを変更できます。進行状況メッセージとは異なり、この変更はビルドが終了した後も持続します。
失敗したビルドのビルドステータスを SUCCESS
に変更することもできます。
ステータスを設定したり、ビルドステータスのテキストを変更したりするには(たとえば、テストフレームワークが TeamCity でサポートされていない場合は失敗したテストの数を書き留めます)、次の形式の buildStatus
メッセージを使用します。
where:
status
(オプション):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 レポート |
コード検査 | |
| 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
、またはcheckstyle
importData メッセージは、エラーと警告の制限を指定するオプションのerrorLimit
およびwarningLimit
属性も取ります。これを超えると、ビルドが失敗します。
複数のディレクトリの監視を開始したり、複数の種類のレポートを解析したりするには、対応するサービスメッセージを次々に送信します。
サービスメッセージによるビルドのキャンセル
スクリプトからビルドをキャンセルする必要がある場合、たとえば、ビルドが環境のせいで正常に続行できない場合、またはサブプロセスからビルドをキャンセルする必要がある場合は、次のサービスメッセージを使用できます。
必要に応じて、キャンセルした後でビルドをキューに再度追加できます。
TeamCity サービスメッセージ経由のライブラリレポート結果
JetBrains および外部ソースからのいくつかのプラットフォーム固有のライブラリは、TeamCity サービスメッセージを介して結果を報告できます。
サービスメッセージ .NET ライブラリ(英語) — .NET アプリケーションから TeamCity サービスメッセージを生成(および解析)するための .NET ライブラリ。関連するブログ投稿(英語)を参照してください。
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(英語) — Mocha JavaScript テストフレームワークのサービスメッセージを介したオンザフライレポート。手順については、関連する投稿(英語)を参照してください。
Karma(英語) — TeamCity サービスメッセージを使用して、テストの進行状況を TeamCity に報告する JavaScript テストツールのサポート
関連ページ:

ビルドの失敗条件 | TeamCity
TeamCity を使用すると、ビルドが失敗としてマークされる条件を変更できます。これらのビルド障害条件はビルド設定 | 障害条件で調整できます。一般的なビルド失敗条件:一般的な障害状態ブロックでは、TeamCity がビルドに失敗する正確な方法を指定できます。実行時間が... 分より長い場合: ビルドの実行タイムアウトを有効にするには、値を分単位で入力します。指定された時間を超えると、ビルドは自動的にキャンセルされます。0 に設定しない限り、このビルド構成設定は、管理 | グローバル設定で指定...

テストメタデータの報告 | TeamCity
TeamCity でのテスト実行は、テストステータス、実行時間、出力を補完するいくつかの追加情報(メタデータ)に関連付けることができます。この情報は、追加のログ、スクリーンショット、数値、タグなどを提供するために使用できます。これで、サービスメッセージを使用して、TeamCity でこの種の追加のテストデータをレポートし、TeamCity WebUI で表示できるようになりました。追加テストデータの報告:追加のテストデータは、サービスメッセージを使用して、次の属性とともに報告されます。(オプシ...