TeamCity オンプレミス 2026.1 ヘルプ

サービスメッセージ

サービスメッセージは、ビルドに関するコマンド / 情報をビルドスクリプトから TeamCity サーバーに渡す特別に構成されたテキストです。

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 は、flowStarted や setParameter などのメッセージの名前です。

  • 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

| （縦線）

||

[ (左角括弧)

|[

] (右角括弧)

|]

ログを作成するためのメッセージのレポート

次のように、メッセージをビルドログに報告できます。

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

where:

  • status は、次の値を取ることができます: NORMAL （デフォルト）、WARNING、FAILURE、ERROR

  • errorDetails は status が ERROR の場合にのみ使用され、それ以外の場合には無視されます。
    このメッセージは、ビルドのステータスが ERROR で、ビルド構成のビルドの失敗条件ページで「ビルドランナーによってエラーメッセージがログに記録された場合、ビルドに失敗する」ボックスがチェックされている場合にビルドを失敗させます。例:

    ##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）。現在、ビルドログでブロック名として使用されています。

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

メッセージ FlowId

すべてのメッセージはオプションの属性 flowId をサポートしており、これによりメッセージを別々のカテゴリ (フロー) にグループ化できます。例: すべてのメッセージは送信順に処理されるため、次のサンプルでは、両方の出力メッセージが最新のブロックによって所有されるブロックの階層が生成されます。

##teamcity[blockOpened name='block 1'] ##teamcity[blockOpened name='block 2'] ##teamcity[message text='Message 1'] ##teamcity[message text='Message 2']
Block without flowID

flowId 属性を追加すると、メッセージを 2 つの並列フローに分割できます。

##teamcity[blockOpened name='block 1' flowId='1'] ##teamcity[blockOpened name='block 2' flowId='2'] ##teamcity[message text='Message 1' flowId='1'] ##teamcity[message text='Message 2' flowId='2']
Block with flowID

ほとんどの場合、メッセージフローを開始するために必要な属性は flowId のみです。ネストされたテストレポートでは、ルートフロー内ではなく、既存のフロー内のサブフローとしてフローを開始する必要がある場合があります。これを行うには、flowStarted パラメーターを追加し、親フロー ID を parent パラメーターとして指定します。指定された親のないフローは、現在のステップのルートフロー内で開始されます。

サブフローを終了するには、flowFinished パラメーターを使用します。親フローを終了すると、そのサブフローもすべて自動的に閉じられますが、フローの順序を明示的に宣言することをお勧めします。

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

flowStarted および flowFinished メッセージは、testStarted メッセージと testFinished メッセージの間に発行された場合にのみ有効であることに注意してください。

レポートテスト

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

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

テストレポートメッセージは、オプションの属性 timestamp をサポートします。次の例では、<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' ...]

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

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

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

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

ネストされたテストレポート

別のテストを開始すると、同じフロー内で現在開始されているテストが終了します。他のテスト内から引き続きテストを報告するには、ネストされたテストサービスメッセージで別の flowId を指定する必要があります。

# TEST SUITE A ##teamcity[testSuiteStarted name='Test Suite A'] # TEST_1_A ##teamcity[testStarted name='Test 1.A' captureStandardOutput='false'] ##teamcity[flowStarted flowId='mainFlow-1a'] # Nested TEST_1_A_1 ##teamcity[testStarted name='Test 1.A, Subtest 1' captureStandardOutput='false'] ##teamcity[flowStarted flowId='subFlow1-1a' parent='mainFlow-1a'] # Testing ##teamcity[flowFinished flowId='subFlow1-1a'] ##teamcity[testFinished name='Test 1.A, Subtest 1' duration='1000'] # Nested TEST_1_A_2 ##teamcity[testStarted name='Test 1.A, Subtest 2' captureStandardOutput='false'] ##teamcity[flowStarted flowId='subFlow2-1a' parent='mainFlow-1a'] # Testing ##teamcity[flowFinished flowId='subFlow2-1a'] ##teamcity[testFinished name='Test 1.A, Subtest 2' duration='1000'] ##teamcity[flowFinished flowId='mainFlow-1a'] ##teamcity[testFinished name='Test 1.A' duration='3000'] ##teamcity[testSuiteFinished name='Test Suite A']

フローのネストに関する詳細については、flowID セクションを参照してください。

開始 / 停止メッセージをテストする

##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 の場合、testStarted メッセージと testFinished メッセージの間で受信されたすべての標準出力および標準エラーメッセージはテスト出力と見なされます。デフォルト値は false です。テスト出力を報告するために testStdOut および testStdErr サービスメッセージの使用を想定しています。

test suite + test name のペアがビルド内で一意であることを確認することを強くお勧めします。高度な TeamCity テスト関連機能が動作するには、テスト名がビルドごとに異なっていてはいけません (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']

テスト再試行の有効化

ビルド構成のテスト再試行のサポートを有効にすることができます。このオプションを有効にすると、テストの実行が成功すると、以前の失敗がミュートされます。つまり、TeamCity は、同じビルド内でテストが失敗してその後成功した場合、そのテストをミュートします。
このようなテストはビルドステータスに影響しません。

##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 — （必須）、上記の inspectionType.id への参照は 255 文字に制限されています。

  • 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。異なる問題は異なる ID、同じ問題を持っている必要があります。同じ ID。同じ問題、たとえば同じコンパイルエラーが発生した場合、ビルド全体で変更されるべきではありません。60 文字までの有効な JavaID である必要があります。省略した場合、identity は description テキストに基づいて計算されます。

ビルドステータスの報告

buildStatus を使用してビルドステータステキストを設定します。

Custom build status
##teamcity[buildStatus text='NuGet packages were successfully published.']

現在進行中の操作をビルドステータスに反映するように設計された進行状況メッセージとは異なり、buildStatus メッセージは、ビルドの完了後に持続する最終的なビルドステータスを設定します。

異なるステップ実行条件を持つ個別のステップを追加して、「グリーン」ビルドと失敗したビルドを区別し、それぞれに異なるカスタムステータスを設定できます。

steps { // ... script { id = "set-custom-green-text" scriptContent = """echo "##teamcity[buildStatus text='NuGet packages were successfully published.']"""" } script { id = "set-custom-red-text" executionMode = BuildStep.ExecutionMode.RUN_ONLY_ON_FAILURE scriptContent = """echo "##teamcity[buildStatus text='Build failed! NuGet packages were not updated.']"""" } }

デフォルトのステータステキストは、{build.status.text} プレースホルダーを介して参照できます。

##teamcity[buildStatus text='The default status of this build is: {build.status.text}']

ステータスパラメーター

buildStatus サービスメッセージのオプションの status パラメーターを使用すると、ビルドの外観をオーバーライドできます。つまり、失敗したビルドを成功としてペイントし、(推奨されませんが) 成功したビルドを失敗としてペイントします。

  • ビルドのステータスを失敗から成功に変更するには、status='SUCCESS' パラメーターを追加します。

    ##teamcity[buildStatus status='SUCCESS' text='{build.status.text}, the build is marked as successful']
    Successful status assigned manually

  • 「緑色」のビルドを失敗として表示したい場合は、次のメッセージを送信できます。

    ##teamcity[buildStatus status='FAILURE' text='The build status was manually switched to {build.status.text}']

    ただし、これはビルドステータスを変更するだけであり、この「失敗した」ビルドを調査している人に実用的なインサイトは提供されないため、代わりに buildProblem メッセージを送信することをお勧めします。このメッセージにより、単に最終ステータスを変更するのではなく、ビルドを実際に失敗させることができます (そして、この問題に関連する具体的な詳細を提供できます)。その結果、プロジェクトの管理者は、問題解決のために TeamCity が提供するさまざまなツール (調査、ミュートなど) を使用できるようになります。

    ##teamcity[buildProblem description='The artifact size has decreased dramatically' identity='2281488']

ビルド番号の報告

カスタムビルド番号を直接設定するには、次の形式で 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[buildStatisticValue key='<valueTypeKey>' value='<value>']

where

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

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

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

出力内のサービスメッセージの検索を無効にする必要がある場合は、次のメッセージを使用してサービスメッセージの検索を無効にすることができます。

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

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

disableServiceMessages コマンドは、それを発行したビルドステップに対してのみサービスメッセージの処理を停止します。そのステップが終了し、新しいステップが開始されると、TeamCity は、後続の enableServiceMessages コマンドがなくても、サービスメッセージの処理を再開します。

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

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 属性も受け取ります。この制限を超えると、ビルドが失敗します。

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

ファイルをビルドログに書き込む

次のサービスメッセージを送信して、ファイルの内容の追跡を開始し、その新しい行をビルドログに書き込みます。

##teamcity[importData type='streamToBuildLog' filePath='path-to-file' wrapFileContentInBlock='false' charset='UTF-8']
Stream file to log

  • type — 常に「streamToBuildLog」と等しくなります。

  • filePath — 特定のファイルへのパス。このパスは絶対パス（filePath='%teamcity.build.checkoutDir%/temp.txt'）または相対パス（filePath='./myFolder/temp.txt'）で指定できます。相対パスは、ビルドを実行するエージェントの現在の作業ディレクトリ（teamcity.agent.work.dir パラメーターによって返されるディレクトリ）を基準に解決されます。指定されたファイルが存在しないか、開けない場合、TeamCity は定期的にこのファイルへのアクセスを再試行します（このサービスメッセージを送信したランナーが実行中である限り）。

  • wrapFileContentInBlock (オプション) — このメッセージの出力を折りたたみ可能な「ストリーミングファイル ...」ブロックに配置するかどうかを指定します。デフォルト値は「true」です。

    Wrap in block

  • charset (オプション) — Java でサポートされるエンコーディングの正規名または別名。引数が存在しない場合、またはエンコーディングを解決できない場合は、UTF-8 が使用されます。

TeamCity は、親ランナーがアクティブである限り、指定されたファイルを監視します。ランナーが停止すると、ファイルは最後までストリーミングされて閉じられます。

カスタム Slack メッセージの送信

TeamCity サービスメッセージを使用して、Slack ダイレクトメッセージを送信し、Slack チャネルに更新を投稿できます。

Custom TeamCity messages in Slack

TeamCity は Slack 接続を使用して Slack メッセージを送信します。Slack 接続がまだない場合は、プロジェクト設定 | 接続に移動して作成してください。

  1. Slack 接続の設定を開き、通知の制限を任意の正の数に設定します。この値は、ビルド構成が実行ごとに送信できるメッセージの最大数を指定します。

  2. セキュリティ上の理由から、メッセージ内では同じ TeamCity サーバーへのリンクのみが許可されます。外部 Web リソースへの URL を含むメッセージは、対応するメッセージが "teamcity-notifications.log" ファイル ( 管理 | 診断 | サーバーログ ) に書き込まれて自動的にブロックされます。

    Blocked service message

    外部リソースへのリンクを含める必要がある場合は、許可されるホスト名フィールドにホスト名を入力します。複数の値を入力するには区切り文字としてコンマ (,) を使用し、文字列のワイルドカードとしてアスタリスク (*) を使用します (*.test.co.uk など)。

  3. Slack 接続が構成されたら、次の形式でサービスメッセージをビルドスクリプトに追加できます。

    ##teamcity[notification notifier='slack' message='Line 1 |rLine2 |rLine3' sendTo='build_farm_alerts' connectionId='PROJECT_EXT_2']

    • notifier — 常に「緩み」に等しくなります。

    • message — 表示するメッセージ。Markdown(英語) 構文をサポートします (改行の "\n" とは別に、代わりに "|n "または"|r" を使用します)。

      Markdown-formatted service messages

    • sendTo — メッセージを受信する人を指定します。単一の Slack チャネル名、チャネル ID (「C」で始まる、たとえば「C052UHDRZU7」)、ユーザー ID (「U」で始まる、たとえば「U02K2UVKJP7」) を値として受け入れます。同じメッセージを複数の受信者に送信する必要がある場合は、異なる sendTo 値を使用して複数のサービスメッセージを作成します。

    • connectionID — TeamCity がこのメッセージの送信に使用する特定の Slack 接続を選択できるオプションのパラメーター。接続 ID を値として受け入れます。このパラメーターが指定されていない場合、TeamCity は現在のプロジェクトで使用可能なすべての Slack 接続を取得し、通知の制限がゼロではない接続を選択します。

  1. ビルドを実行して、すべての Slack メッセージが配信されることを確認します。

カスタムメールメッセージの送信

TeamCity サービスメッセージを使用して、ビルドスクリプト内からメールを送信できます。

Email delivered by a service message

  1. 管理 | メール通知に移動し、送信者のメール、SMTP ログインとパスワード、接続セキュリティプロトコルなどの共通通知機能設定をセットアップします。例については、リンク GoogleMail を通知サーバーとして設定するを参照してください。

  2. 通知の制限設定を任意の正の数に設定します。この値は、ビルド構成が実行ごとに送信できるメッセージの最大数を指定します。

  3. 受信者のリストを許可されたアドレスに入力します。このリスト以外の受信者に送信されたメッセージは、自動的にブロックされます。複数のアドレスを入力するには区切り文字としてコンマ (,) を使用し、文字列のワイルドカードとしてアスタリスク (*) を使用します (*@gmail.com など)。

  4. セキュリティ上の理由から、メッセージ内では同じ TeamCity サーバーへのリンクのみが許可されます。外部 Web リソースへの URL を含むメッセージは、対応するメッセージが "teamcity-notifications.log" ファイル ( 管理 | 診断 | サーバーログ ) に書き込まれて自動的にブロックされます。

    Blocked service message

    外部リソースへのリンクを含める必要がある場合は、許可されるホスト名フィールドにホスト名を入力します。複数の値を入力するには区切り文字としてコンマ (,) を使用し、文字列のワイルドカードとしてアスタリスク (*) を使用します (*.test.co.uk など)。

  5. Email Notifier を設定したら、次の形式でサービスメッセージをビルドスクリプトに追加できます。

    ##teamcity[notification notifier='email' message='Message body' subject='Email subject' address='user1@gmail.com,user2@yourcompany.com']

    • notifier — 常に「メール」と等しくなります。

    • message — メッセージ本文はプレーンテキスト形式です。

    • subject — メールの件名。

    • address — Email Notifier の許可されたアドレスリストからの 1 つまたは複数のアドレス。

  6. ビルドを実行して、すべてのメールが配信されることを確認します。

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

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

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

必要に応じて、キャンセル後にビルドをキューに再度追加できます。デフォルトでは、TeamCity はビルドをキューに再追加するために 3 回試行します。

ダウンストリームチェーンビルドは、先行する (アップストリーム) 構成から skipQueuedBuilds メッセージを送信することでキャンセルできます。このメッセージは、スキップする構成の ID またはタグを tags パラメーターとして受け入れます。

##teamcity[skipQueuedBuilds tags='value1,value2,...' comment='Your comment']

ビルドチェーンにリンクされたビルドをキャンセルする方法の詳細については、部分的なチェーン実行の記事を参照してください。

ビルドタグの追加と削除

サービスメッセージを使用すると、ビルドタグを追加および削除できます。

  • ##teamcity[addBuildTag 'your-custom-tag'] — 現在のビルドに新しいタグを追加します。

  • ##teamcity[removeBuildTag 'tag-to-remove'] — 現在のビルドからタグを削除します。

どちらのメッセージでも、プレーンな文字列の代わりに構成パラメーターの値を渡すことができます。例: ##teamcity[addBuildTag '%teamcity.agent.jvm.os.name%'] メッセージタグは、エージェントマシンにインストールされているオペレーティングシステムの名前で構築されます。

Tagging builds with OS names

1 つのサービスメッセージで 1 つのタグを追加または削除できます。複数のタグを追加または削除するには、複数のサービスメッセージを送信します。

TeamCity サービスメッセージを介したライブラリレポート結果

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

Perforce サービスメッセージ

パフォーマンスプロジェクトと連携したパーソナルビルドは、最後の「個人の変更を元に戻す」段階で失敗する可能性があります。これは通常、この段階が始まる前にコードソースチェックアウトディレクトリが使用できなくなった場合に発生します (たとえば、Bootstrap ビルドステップによってマウントされ、最後のビルドステップの後に自動的にアンマウントされた場合など)。

このような場合、ビルドステップの実行中に、TeamCity が通常行うよりも早く個人の変更を元に戻す必要があります。これを行うには、最後のビルドステップ中に次のサービスメッセージを送信します。

##teamcity[undoPersonalPatch]
2025 年 6 月 30 日
TeamCity とスクリプトの相互作用を構築する teamcity-info.xml

関連ページ：

ビルドの失敗条件

TeamCity では、ビルドが失敗とマークされる条件を変更できます。これらのビルド失敗条件は、ビルド設定 | 失敗条件で調整できます。一般的なビルドの失敗条件：一般的な障害状態ブロックでは、TeamCity がビルドにどの程度正確に失敗するかを指定できます。カスタムビルド実行タイムアウトの設定 ... 分以上実行された場合条件はビルド実行のタイムアウトを設定します。ビルドが指定された時間（分単位）を超えると、自動的にキャンセルされます。これにより、ビルドのハングを防ぎ、エージェントの効率性が向上...

ビルド結果ページ

TeamCity では、ビルドに関するすべての情報 (キューに入っているか、実行中か、完了しているかに関係なく) がビルド結果ページに蓄積されます。ビルド結果を表示するには、任意の構成を選択してビルド履歴を表示し、必要なビルド番号をクリックします。This page includes several static tabs (Overview, Changes, Build Log, Artifacts, and others), as well as contextual tabs whose...

テストメタデータの報告

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

プロジェクト管理者ガイド

このセクションでは、プロジェクト管理に焦点を当てます。TeamCity プロジェクトとビルド構成の作成、ビルドステップの設定、依存関係チェーンの構成などについて説明します。基本的な TeamCity ワークフロー：次のダイアグラムは、基本的な TeamCity ワークフローを示しています。TeamCity サーバーはリポジトリの変更を検出しました。サーバーはこの変更をデータベースに書き込みます。ビルド構成に添付されたトリガーは、データベース内の関連する変更を検出し、ビルドを開始します。トリガー...

ビルド結果を扱う

TeamCity には、ホームと設定という 2 つのメインモードがあります。ホームモードでは、プロジェクトレベルとビルド構成レベルでビルド結果が蓄積されます。新しい TeamCity UI を使用している場合は、プロジェクトサイドバーを介してこの階層間を移動できます。各モードには、独自の詳細レベルがあります。プロジェクト全体のビルド統計を確認するには、プロジェクトホームにアクセスしてください。単一のビルド構成の詳細を参照するには、その名前をクリックしてビルド構成ホームを開きます。ホームページで特...

ビルドステップの実行条件

ビルドステップを構成するときに、一般的な実行ポリシーを選択し、TeamCity 2020.1 以降ではパラメーターベースの実行条件を追加できます。実行条件により、ビルドがより柔軟になり、次のような多くの一般的な使用例に対応します。デフォルトのブランチでのみステップを実行する、ブランチでのみステップを実行する、個人ビルドのステップをスキップする、ビルドステップの条件を追加メニューで使用可能な共通オプションをすばやく選択できます。または、その他の状態オプションを選択して、パラメーターベースの実行条件...