サービスメッセージ
サービスメッセージは、ビルドに関するコマンドや情報をビルドスクリプトから TeamCity サーバーへ渡すために特別に構成されたテキストです。
TeamCity で処理されるには、 ビルドの標準出力ストリームに書き込む、つまりビルドステップから print または echo で出力する必要があります。
例:
単一のサービスメッセージの内部に改行文字を含めることはできず、複数行にまたがることもできません。
サービスメッセージのフォーマット
サービスメッセージは 2 つのフォーマットをサポートします。
単一属性メッセージ
##teamcity[<messageName> 'value']複数属性メッセージ
##teamcity[<messageName> name1='value1' name2='value2']複数属性メッセージは、より正式には次のように説明できます。
##teamcity[messageNameWSPpropertyNameOWSP=OWSP'value'WSPpropertyName_IDOWSP=OWSP'value'...OWSP]
where:
メッセージ名は、フロー開始やパラメーターを設定などのメッセージの名前です。プロパティ名は、メッセージ属性の名前です。 有効な Java ID でなければなりません。値は属性の値です。 エスケープされた値である必要があります。WSPは必須の空白です: スペースまたはタブ文字（タブ）。OWSPはオプションの空白です。…は、任意の数のWSPプロパティ名OWSP=OWSP'値'ブロックです。
エスケープされた値
エスケープされた値では、TeamCity は垂直バー または をエスケープ文字として使用します。 特定の特殊文字が TeamCity サーバーで正しく解釈されるようにするには、その前に垂直バーを付ける必要があります。 例: 次のメッセージ:
TeamCity では foo のテスト として表示されます。 以下のエスケープ値の表を参照してください。
文字 | として逃げる |
|---|---|
' (アポストロフィ) | |' |
\n (改行) | | n |
\r (復帰) | | r |
\uNNNN (コード 0xNNNN の Unicode シンボル) | | 0xNNNN |
| （縦線） | || |
[ (左角括弧) | |[ |
] (右角括弧) | |] |
ビルドログへのメッセージの報告
次のように、メッセージをビルドログに報告できます。
where:
状況は、次の値を取ることができます:通常（デフォルト）、警告、失敗、エラーエラー詳細は、状況がエラーの場合にのみ使用され、それ以外の場合は無視されます。
このメッセージは、ステータスがエラーであり、「ビルドランナーによってエラーメッセージがログに記録された場合にビルドを失敗させる 」ボックスがビルド構成の ビルド失敗条件 ページでオンになっている場合、ビルドを失敗させます。 例:##teamcity[message text='Exception text' errorDetails='stack trace' status='ERROR']
サービスメッセージのブロック
ブロックはビルドログ内のいくつかのメッセージをグループ化するために使用されます。
ブロックオープニング:
ブロック開始 システムメッセージには お名前 属性があり、説明を追加することもできます。
ブロックを閉じる:
コンパイルメッセージの報告
where:
コンパイラー_お名前は、コンパイルを実行するコンパイラーの任意の名前です（例:javacまたはgroovyc）。 現在、ビルドログでブロック名として使用されています。コンパイル開始とコンパイル終了の間で報告されたステータスエラーのメッセージは、コンパイルエラーとして扱われます。
メッセージ FlowId
すべてのメッセージはオプションの属性 フロー ID をサポートしており、これによりメッセージを別々のカテゴリ (フロー) にグループ化できます。 例: すべてのメッセージは送信順に処理されるため、次のサンプルでは、両方の出力メッセージが最新のブロックによって所有されるブロックの階層が生成されます。
フロー ID 属性を追加すると、メッセージを 2 つの並列フローに分割できます。
ほとんどの場合、メッセージフローを開始するために必要な属性は フロー ID のみです。 ネストされたテストレポート では、ルートフロー内ではなく、既存のフロー内のサブフローとしてフローを開始する必要がある場合があります。 これを行うには、 フロー開始 パラメーターを追加し、親フロー ID を 親 パラメーターとして指定します。 指定された親のないフローは、現在のステップのルートフロー内で開始されます。
サブフローを終了するには、 フロー終了 パラメーターを使用します。 親フローを終了すると、そのサブフローもすべて自動的に閉じられますが、フローの順序を明示的に宣言することをお勧めします。
フロー開始 および フロー終了 メッセージは、 テスト開始 メッセージと テスト終了 メッセージの間に発行された場合にのみ有効であることに注意してください。
テストの報告
TeamCity のオンザフライテストレポートを使用するには、テストフレームワークがこの機能を動作させるための専用サポートを備えている必要があります (または、 XML レポート処理を使用できます)。 TeamCity がテストフレームワークをネイティブにサポートしていない場合は、サービスメッセージを使用して TeamCity サーバーにテスト実行を報告するようにビルドスクリプトを変更できます。 これにより、テスト結果をリアルタイムで表示し、 ビルド結果 ページの テスト タブでテスト情報を利用できるようになります。
メッセージ作成タイムスタンプ
テストレポートメッセージは、オプションの属性 タイムスタンプ をサポートします。 次の例では、 <メッセージ名> は特定のサービスメッセージの名前です。
タイムスタンプの形式は、 Java SimpleDateFormat の構文(英語)に従って yyyy-MM-dd'T'HH:mm:ss.SSSZ または yyyy-MM-dd'T'HH:mm:ss.SSS です。
例:
.NET DateTimeOffset(英語) の場合、このようなコード
結果:
サポートされるテストサービスメッセージ
テスト suite メッセージ：: テストスイートは、テストをグループ化するために使用されます。 TeamCity は、 ビルド結果 ページの テスト タブやその他の場所で、suite ごとにグループ化されたテストを表示します。
すべての個々のテストメッセージは、同じ お名前 属性を持つ テスト suite 開始 と テスト suite 終了 の間に（この順序で）表示されます。
ネストされたテストレポート
別のテストを開始すると、同じ フロー内で現在開始されているテストが終了します。 他のテスト内から引き続きテストを報告するには、ネストされたテストサービスメッセージで別の フロー ID を指定する必要があります。
フローのネストに関する詳細については、 flowID セクションを参照してください。
テスト開始/停止メッセージ：
テスト名 が実行されたことを示します。 テスト失敗 メッセージが存在しない場合、テストは成功したと見なされます。
期間(オプションの数値整数属性) は、TeamCity UI で報告されるテスト時間をミリ秒単位で設定します。 省略した場合、テスト期間はメッセージのタイムスタンプから計算されます。 タイムスタンプが欠落している場合 — サーバーでメッセージが実際に受信された時刻から。標準出力のキャプチャ(オプションのブール属性) —真の場合、テスト開始メッセージとテスト終了メッセージの間で受信されたすべての標準出力および標準エラーメッセージは、テスト出力と見なされます。 デフォルト値は偽です。テスト出力を報告するためにテスト標準出力およびテスト標準エラーサービスメッセージの使用箇所を想定します。
テスト suite + テスト名 のペアがビルド内で一意であることを確認することを強くお勧めします。 高度な TeamCity テスト関連機能を動作させるには、テスト名がビルドごとに変わらないようにする必要があります (単一のテストはすべてのビルドで同じ名前で報告される必要があります)。 報告されるテスト名に絶対パスを含めることは 強く非推奨。
無視されたテスト：
テスト名 は存在するが、テストフレームワークによって実行されなかった（無視された）ことを示します。 例外として、 テスト無視 メッセージは、一致する テスト開始 および テスト終了 メッセージなしで報告できます。
テスト出力：
テスト標準出力 および テスト標準エラー サービスメッセージは、TeamCity UI に表示されるテストの標準出力およびエラー出力を報告します。 テストごとに 1 つの テスト標準出力 メッセージと 1 つの テスト標準エラー メッセージだけがなければなりません。 代替方法ですが、信頼性の低い方法は、 テスト開始 メッセージの 標準出力のキャプチャ 属性を使用することです。
テスト結果：
テスト名 テストが失敗したことを示します。 特定のテスト名に対して表示できる テスト失敗 メッセージは 1 つだけです。
メッセージには、エラーのテキスト表現が含まれています。詳細には、テスト失敗に関する詳細情報（通常はメッセージと例外スタックトレース）が含まれています。実際および期待値属性は、比較の失敗を報告するためにタイプ='比較失敗'と一緒にしか使用できません。 IDE でテストを開くときに値が使用されます。
以下はサービスメッセージを使ったテストレポートのより長い例です。
テスト再試行の有効化
ビルド構成で テスト再試行のサポートを有効化できます。 このオプションを有効化すると、テストの実行が成功した場合に以前の失敗がミュートされます。つまり、同じビルド内でテストが失敗した後に成功すると、TeamCity はそのテストをミュートします。
このようなテストはビルドステータスに影響しません。
テスト名の解釈
完全なテスト名の形式は <suite お名前>: <パッケージ/名前空間お名前>.<クラスお名前>.<テストメソッド>(<テストパラメーター>) にできます。ここで、 <クラスお名前> と <テストメソッド> の名前にはドットを含めることはできません。 完全なテスト名で必須の部分は <テストメソッド> のみです。
完全なテスト名は、結果のビルド間でテストを比較したり、異なるビルド構成間でテストを一致させるために使用されます。
完全なテスト名の例:
ビルド結果 ページの テスト タブでは、スイート、パッケージ / 名前空間、クラス、テストごとにグループ化できます。 通常、属性値はテストフレームワークによって報告されたとおりに提供され、TeamCity はテスト名を正しく解釈できます。
上記の形式でテストを構文解析できない場合でも、TeamCity は Tests タブでのフィルタリングのために完全なテスト名から <suite お名前> を抽出しようとし、suite の後のすべてを構文解析できないテスト名として扱います。
追加テストデータの報告
テストメタデータ サービスメッセージを使用して、テストに追加情報をアタッチすることができます。 詳細については、 別のページを参照してください。
.NET コードカバレッジ結果の報告
サービスメッセージを使用して .NET カバレッジ処理を設定できます。 詳細については、 レポートカバレッジの手動構成ページを参照してください。
インスペクションの報告
以下で説明するサービスメッセージを使用して、カスタムツールから TeamCity にインスペクションを報告できます。
他の用途の中でも、インスペクションの数は、 ビルドを失敗させるためのビルドメトリクスとして使用できます。
インスペクションタイプ
コード内の特定の警告またはエラー (インスペクションインスタンス) には、インスペクションタイプがあります。これは、実行されたインスペクションの一意の説明であり、次を介して報告できます
ここで、すべての属性が必須であり、数値またはテキスト値を使用できます。
ID— （必須）255 文字以内お名前— （必須）255 文字以内カテゴリ— （必須）255 文字までに制限されています。カテゴリ属性の例は、「スタイル違反」および「発呼契約」です。説明— （必須）4000 文字に制限されています。 説明は HTML にすることもできます。 例:
インスペクションインスタンス
特定の不具合、警告、エラーメッセージを報告します。 場所、説明、さまざまなオプションおよびカスタム属性が含まれています。
ここで、すべての属性は数値またはテキスト値を持つことができます。
タイプ ID— （必須）、 上記のインスペクションタイプ.IDへの参照は 255 文字に制限されています。メッセージ— （オプション）現在のインスタンスの説明は 4000 文字に制限されています。ファイル— （必須）ファイルパスは 4000 文字に制限されています。 パスは、絶対パスまたは チェックアウトディレクトリからの相対パスにすることができます。行— （オプション）ファイルの行、整数。追加属性– 任意の属性にできます。ここでは重大度がよく使用され、次のいずれかの値を指定します (大文字に注意してください):情報、エラー、警告、弱い警告。
例:
ビルド進行中のアーティファクトの公開
ビルドの実行中に、アーティファクトがビルドされた直後に、ビルドアーティファクトを公開することができます。
これを行うには、次の行を出力する必要があります。
<パス> は、 ビルド構成設定 の アーティファクト仕様の構築と同じ規則に従う必要があります。 <パス> に一致するファイルがアップロードされ、実行中のビルドのアーティファクトとして表示されます。
すべてのファイルの準備が整い、ファイルが読み取り用にロックされていないときにメッセージが表示されます。
アーティファクトはバックグラウンドでアップロードされるため、時間がかかることがあります。 ビルドステップが終了するまで、一致するファイルが削除されないようにしてください (たとえば、次のビルド開始時にクリーンアップされるディレクトリ、 一時ディレクトリに配置するか、ビルド後に Swabra を使用してクリーンアップします)。
ビルド構成設定で指定されたアーティファクトは、最後のビルドステップの終了後に通常どおり公開されます。
ステップ間での NuGet パッケージの受け渡し
NuGet パッケージを公開してから単一のビルド内でその内容を使用する必要がある場合、ビルドの終了時ではなく、時間どおりに公開および索引付けされることを保証したいはずです。
そのためには、 NuGet Publish ランナーを使用するか、代わりに任意のステップで ##teamcity[publishNuGetPackage] サービスメッセージを送信できます。 これにより、NuGet パッケージは現在のステップの終了時に、構成済みのすべての NuGet フィードに公開され、以降のビルドステップで利用できるようになります。
ビルド進捗の報告
特別な進行状況メッセージを使用して、ビルドスクリプトで実行時間の長い部分をマークできます。 これらのメッセージは、対応するビルドのプロジェクトのダッシュボードと ビルド結果 ページに表示されます。
単一の進捗メッセージを記録するには、次のようにします。
この進行メッセージは、別の進行メッセージが表示されるまで、または次のターゲットが起動するまで表示されます（Ant ビルドの場合）。
ビルドの一部だけの進行状況メッセージを表示したい場合は、次のようにします。
ビルドの問題の報告
ビルドスクリプトから直接ビルドを失敗させるには、ビルドの問題を報告する必要があります。 ビルドの問題は、ビルドステータステキストに影響します。 それらは ビルド結果 ページに表示されます。 ビルドにビルドの問題を追加するには、次を使用します。
where:
説明（必須）: ビルドの問題を説明する人間が読めるプレーンテキスト。 デフォルトでは、説明はビルドステータステキストとビルドの問題のリストに表示されます。 テキストは 4000 シンボルに制限されており、制限を超えると切り捨てられます。識別子(オプション): 一意の問題 ID。 異なる問題には異なる ID が必要であり、同じ問題には同じ ID が必要です。たとえば同じコンパイルエラーが発生した場合など、同じ問題であればビルド全体を通じて変更されるべきではありません。 有効な Java ID で、最大 60 文字である必要があります。 省略した場合、識別子は説明テキストに基づいて計算されます。
ビルドステータスの報告
ビルドステータス弱いAIを誘導する可能性があるプロンプト：A string with same tags/placeholders as source: none. を使用して ビルドステータステキスト を設定します。
現在進行中の操作をビルドステータスに反映するように設計された 進行状況メッセージとは異なり、 ビルドステータス弱いAIを誘導する可能性があるプロンプト：A string with same tags/placeholders as source: none. メッセージは、ビルドの完了後に持続する最終的なビルドステータスを設定します。
異なる ステップ実行条件を持つ個別のステップを追加して、「グリーン」ビルドと失敗したビルドを区別し、それぞれに異なるカスタムステータスを設定できます。
デフォルトのステータステキストは、 {build.status.text} プレースホルダーを介して参照できます。
ステータスパラメーター
任意の 状況 パラメーターを ビルドステータス弱いAIを誘導する可能性があるプロンプト：A string with same tags/placeholders as source: none. サービスメッセージで使用すると、ビルドの見た目をオーバーライドできます。失敗したビルドを成功として表示し、(非推奨ですが) 成功したビルドを失敗として表示できます。
ビルドのステータスを失敗から成功に変更するには、
ステータス='成功'パラメーターを追加します。##teamcity[buildStatus status='SUCCESS' text='{build.status.text}, the build is marked as successful']
「緑色」のビルドを失敗として表示したい場合は、次のメッセージを送信できます。
##teamcity[buildStatus status='FAILURE' text='The build status was manually switched to {build.status.text}']ただし、これはビルドステータスを変更するだけであり、この「失敗した」ビルドを調査している人に実用的なインサイトは提供されないため、代わりに
ビルド問題メッセージを送信することをお勧めします。 このメッセージにより、単に最終ステータスを変更するのではなく、ビルドを実際に失敗させることができます (そして、この問題に関連する具体的な詳細を提供できます)。 その結果、プロジェクトのメンテナーは、課題を解決するために TeamCity が提供するさまざまなツールを使用できるようになります: 調査、ミュートなど。##teamcity[buildProblem description='The artifact size has decreased dramatically' identity='2281488']
ビルド番号の報告
カスタムビルド番号を直接設定するには、次の形式で ビルド番号 メッセージを指定してください。
<新しいビルド番号>値では、TeamCity によって自動生成された現在のビルド番号を使用するために、 {build.number} 置換を使用できます。 例:
ビルドパラメーターの追加または変更
専用のサービスメッセージをビルドスクリプトで使用すると、ビルドステップから直接、そのビルドのビルドパラメーターを動的に更新できます (パラメーターはビルド構成の パラメーター セクションで定義されている必要があります)。 変更されたビルドパラメーターは、変更を行ったステップの後に続くビルドステップで利用できるようになります。 また、ビルドパラメーターとしても利用でき、 %\dep.*% パラメーター参照 を介して依存ビルドで使用できます。例：
ビルドパラメーターの名前を指定するときは、接頭辞に注意してください。
システムプロパティの
system環境変数用の
環境構成パラメーターの接頭辞はありません。
ビルドパラメーターとその接頭辞についての 続きを読む。
ビルド統計の報告
TeamCity では、統計データを報告し、そのデータに基づいてチャートを表示するようにビルドスクリプトを構成できます。 Web UI でチャートを表示するためのガイドについては、 統計チャートのカスタマイズページを参照してください。 このセクションでは、サービススクリプトを介してビルドスクリプトから統計データを報告する方法について説明します。 ビルド統計値は、2 つの方法で公開できます。
ビルドスクリプトでサービスメッセージを直接使用する
teamcity-info.xml ファイルを使用してデータを提供する
サービスメッセージを使用してビルド統計を報告する: 報告する統計値ごとに、ビルド統計値サービスメッセージを次の形式で指定します。
where
キーは 事前定義されたキーのいずれとも等しくてはいけません。値は最大 13 桁の正または負の整数である必要があります。小数点以下 6 桁までの浮動小数点値もサポートされています。
サービスメッセージ処理の無効化
出力内のサービスメッセージの検索を無効にする必要がある場合は、次のメッセージを使用してサービスメッセージの検索を無効にすることができます。
これら 2 つの間に表示されるメッセージは、サービスメッセージとして解析されず、事実上無視されます。 サーバー側のサービスメッセージの処理では、サービスメッセージの有効化 / 無効化も フロー ID 属性をサポートし、同じ フロー ID のメッセージのみを無視します。
サービスメッセージを無効にする コマンドは、それを発行したビルドステップに対してのみサービスメッセージの処理を停止します。 そのステップが終了して新しいステップが開始されると、TeamCity は、後続の サービスメッセージを有効にする コマンドがなくても、サービスメッセージの処理を再開します。
XML レポートのインポート
UI ビルド機能に加えて、 データのインポート サービスメッセージを使用して、ビルドスクリプト内から 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 レポート |
注:
パス属性の特定のファイルのみをサポートします。インストールされた FindBugs ツールのホームディレクトリを指すように指定された
FindBugs ホーム属性も必要です。<ツールお名前>がdotCover、PartCover、NCoverまたはNCover 3のいずれかであるtool='<ツールお名前>'サービスメッセージ属性も必要です。
特記しない限り、レポートタイプは パス 属性で Ant のようなワイルドカードをサポートします。
詳細='true'属性はビルドログへの詳細なログインを可能にします。期限切れを解析='true'属性は、パスに一致するすべてのファイルを処理します。 デフォルトでは、ビルド中に更新されたもの（最後の修正タイムスタンプによって決定されたもの）のみが処理されます。 一致しないレポートが見つかった場合は、「レポートが期限切れとしてスキップされました」というメッセージがビルドログに表示されます。whenNoDataPublished=<アクション>（<アクション>は次のいずれかです:情報（デフォルト）、なし、警告、エラー）は、指定されたパスに一致するレポートが見つからなかった場合、出力レベルを変更します。(非推奨です。代わりに ビルド失敗条件 を使用してください)
FindBugs、PMDまたはチェックスタイルの importData メッセージは、エラー数と警告数の上限を指定する任意のエラー制限属性と警告制限属性も受け入れます。これらの上限を超えると、ビルドが失敗します。
複数のディレクトリの監視を開始したり、複数の種類のレポートを解析したりするには、対応するサービスメッセージを次々に送信します。
ファイルのビルドログへの書き込み
次のサービスメッセージを送信して、ファイルの内容の追跡を開始し、その新しい行をビルドログに書き込みます。
タイプ— 常に「streamToBuildLog」と等しくなります。ファイルパス— 特定のファイルへのパス。 このパスは絶対パス（ファイルパス='%teamcity.build.checkoutDir%/temp.txt'）または相対パス（ファイルパス='./myFolder/temp.txt'）で指定できます。 相対パスは、ビルドを実行するエージェントの現在の作業ディレクトリ（teamcity.エージェント.作業.ディレクトリパラメーターによって返されるディレクトリ）を基準に解決されます。 指定されたファイルが存在しないか開けない場合、TeamCity はこのファイルへのアクセスを定期的に再試行します (このサービスメッセージを送信したランナーが実行中である限り)。
ファイル内容をブロックでラップ(オプション) — このメッセージの出力を折りたたみ可能な「ストリーミングファイル ...」ブロックに配置するかどうかを指定します。 デフォルト値は「true」です。
文字セット(オプション) — Java でサポートされるエンコーディングの正規名または別名。 引数が存在しない場合、またはエンコーディングを解決できない場合は、UTF-8 が使用されます。
TeamCity は、親ランナーがアクティブである限り、指定されたファイルを監視します。 ランナーが停止すると、ファイルは最後までストリーミングされて閉じられます。
カスタム Slack メッセージの送信
TeamCity サービスメッセージを使用して、Slack ダイレクトメッセージを送信し、Slack チャンネルに更新を投稿できます。
TeamCity は Slack 接続を使用して Slack メッセージを送信します。 Slack 接続がまだない場合は、 プロジェクト設定 | 接続 に移動して作成してください。
Slack 接続の設定を開き、 通知制限 を任意の正の数に設定します。 この値は、ビルド構成が実行ごとに送信できるメッセージの最大数を指定します。
セキュリティ上の理由から、メッセージ内では同じ TeamCity サーバーへのリンクのみが許可されます。 外部 Web リソースへの URL を含むメッセージは、対応するメッセージが "teamcity-notifications.log" ファイル (管理 | 診断 | サーバーログ) に書き込まれて自動的にブロックされます。
外部リソースへのリンクを含める必要がある場合は、 許可されたホスト名 フィールドにホスト名を入力します。 複数の値を入力するには区切り文字としてコンマ (,) を使用し、文字列のワイルドカードとしてアスタリスク (*) を使用します (*.test.co.uk など)。
Slack 接続が構成されたら、次の形式でサービスメッセージをビルドスクリプトに追加できます。
##teamcity[notification notifier='slack' message='Line 1 |rLine2 |rLine3' sendTo='build_farm_alerts' connectionId='PROJECT_EXT_2']通知機能— 常に「緩み」に等しくなります。メッセージ— 表示するメッセージ。 Markdown 構文をサポートします (改行には "\n" ではなく、 代わりに "|n" または "|r" を使用してください)。
送信先— メッセージを受信する人を指定します。 単一の Slack チャネル名、チャネル ID (「C」で始まる、たとえば「C052UHDRZU7」)、ユーザー ID (「U」で始まる、たとえば「U02K2UVKJP7」) を値として受け入れます。 同じメッセージを複数の受信者に送信する必要がある場合は、異なる送信先値を使用して複数のサービスメッセージを作成します。接続 ID— TeamCity がこのメッセージの送信に使用する特定の Slack 接続を選択できるオプションのパラメーター。 接続 ID を値として受け入れます。 このパラメーターが指定されていない場合、TeamCity は現在のプロジェクトで使用可能なすべての Slack 接続を取得し、 通知制限 がゼロではない接続を選択します。
ビルドを実行して、すべての Slack メッセージが配信されることを確認します。
カスタムメールメッセージの送信
TeamCity サービスメッセージを使用して、ビルドスクリプト内からメールを送信できます。
管理 | メール通知 に移動し、送信者のメール、SMTP ログインとパスワード、接続セキュリティプロトコルなどの共通 通知機能設定をセットアップします。 例については、リンク Google Mail を通知サーバーとしてセットアップする を参照してください。
通知制限 設定を任意の正の数に設定します。 この値は、ビルド構成が実行ごとに送信できるメッセージの最大数を指定します。
受信者のリストを 許可されたアドレス に入力します。 このリスト以外の受信者に送信されたメッセージは、自動的にブロックされます。 複数のアドレスを入力するには区切り文字としてコンマ (,) を使用し、文字列のワイルドカードとしてアスタリスク (*) を使用します (*@gmail.com など)。
セキュリティ上の理由から、メッセージ内では同じ TeamCity サーバーへのリンクのみが許可されます。 外部 Web リソースへの URL を含むメッセージは、対応するメッセージが "teamcity-notifications.log" ファイル (管理 | 診断 | サーバーログ) に書き込まれて自動的にブロックされます。
外部リソースへのリンクを含める必要がある場合は、 許可されたホスト名 フィールドにホスト名を入力します。 複数の値を入力するには区切り文字としてコンマ (,) を使用し、文字列のワイルドカードとしてアスタリスク (*) を使用します (*.test.co.uk など)。
Email Notifier を設定したら、次の形式でサービスメッセージをビルドスクリプトに追加できます。
##teamcity[notification notifier='email' message='Message body' subject='Email subject' address='user1@gmail.com,user2@yourcompany.com']通知機能— 常に「メール」と等しくなります。メッセージ— メッセージ本文はプレーンテキスト形式です。件名— メールの件名。アドレス— Email Notifier の 許可されたアドレス リストからの 1 つまたは複数のアドレス。
ビルドを実行して、すべてのメールが配信されることを確認します。
サービスメッセージによるビルドのキャンセル
スクリプトからビルドをキャンセルする必要がある場合、たとえば、ビルドが環境のせいで正常に続行できない場合、サブプロセスからビルドをキャンセルする必要がある場合は、次のサービスメッセージを使用できます。
必要に応じて、キャンセル後にビルドをキューに再度追加できます。 デフォルトでは、TeamCity はビルドをキューに再追加するために 3 回試行します。
ダウンストリームチェーンビルドは、先行する (アップストリーム) 構成から キューに入っているビルドをスキップ メッセージを送信することでキャンセルできます。 このメッセージは、スキップする構成の ID またはタグを タグ パラメーターとして受け入れます。
ビルドチェーンにリンクされたビルドをキャンセルする方法の詳細については、 部分的なチェーン実行 の記事を参照してください。
ビルドタグの追加と除去
サービスメッセージを使用すると、 ビルドタグを追加および削除できます。
##teamcity[addBuildTag 'カスタムタグ']— 現在のビルドに新しいタグを追加します。##teamcity[removeBuildTag '削除するタグ']— 現在のビルドからタグを削除します。
どちらのメッセージでも、プレーンな文字列の代わりに 構成パラメーターの値を渡すことができます。 例: ##teamcity[addBuildTag '%teamcity.agent.jvm.os.name%'] メッセージタグは、エージェントマシンにインストールされているオペレーティングシステムの名前で構築されます。
1 つのサービスメッセージで 1 つのタグを追加または削除できます。 複数のタグを追加または削除するには、複数のサービスメッセージを送信します。
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 Listener 1、 PHPUnit Listener 2 — PHPUnit の
suite.xmlを介してプラグインし、テスト用の TeamCity サービスメッセージを生成できるリスナーです。TeamCity への Python ユニットテストレポート — サービスメッセージを介して TeamCity サーバーにユニットテストを自動的に報告するパッケージ (TeamCity の下で実行され、テストコードがそれを使用するように適合されている場合)。
Mocha(英語) — Mocha JavaScript テストフレームワークのサービスメッセージを介したオンザフライレポート。 手順については、関連する 投稿(英語)を参照してください。
Karma — TeamCity サービスメッセージを使用して、テストの進捗を TeamCity に報告するための JavaScript テストツールでのサポート。
Perforce サービスメッセージ
パフォーマンスプロジェクトと連携した パーソナルビルドは、最後の「個人の変更を元に戻す」段階で失敗する可能性があります。 これは通常、この段階が始まる前にコードソースチェックアウトディレクトリが使用できなくなった場合に発生します (たとえば、 Bootstrap ビルドステップによってマウントされ、最後のビルドステップの後に自動的にアンマウントされた場合など)。
このような場合、ビルドステップ実行中に、TeamCity が通常行うよりも早く個人の変更を元に戻す必要があります。 これを行うには、最後のビルドステップ中に次の サービスメッセージを送信します。