ビルドとテストの失敗への対処

ビルド結果ページ

ビルド結果ページには、この個々のビルド実行に関する最も詳細な情報が表示されます。概要タブには、この実行中に発生したビルドとテストの問題の概要を示す展開可能なセクションが表示されます。

ビルドの問題が初めて発生すると、ビルドのステータスメッセージに「(新規)」が追加されます。これにより、ビルド履歴をスクロールするときに、固有の問題と繰り返し発生する問題をすばやく区別できます。

問題をクリックすると、その問題に対応するビルドログの一部が表示されます。

失敗したテストでは、現在の障害 / 最初の失敗トグルも表示され、繰り返し発生する問題が最初に発生したビルドにすばやく移動できます。

新しいビルドが同じテストに失敗することなく完了しているのに、古いビルドの結果を表示している場合、失敗は取り消し線で表示されます。この場合、この新しいビルドを指すすでに修正済みタブが表示されます。

テストのステータスが失敗から成功に頻繁に変化する場合、TeamCity はそのようなテストを flaky としてマークします。詳細については、専用の不安定なテストセクションを参照してください。

問題タブ

プロジェクトの問題タブには、子サブプロジェクトの問題も含め、現在アクティブなすべてのビルドの問題の概要が表示されます。

このページでは、ビルドとテストの失敗を切り替えたり、問題を状態別にフィルタリングしたりできます。

調査

調査対象の問題は、TeamCity ユーザーが割り当てられている問題です。これらのユーザーは、対応するビルドの問題やテストの失敗を修正する責任があります。

ユーザーに割り当てられた調査の合計数は、TeamCity ヘッダーに表示されます。この UI 要素をクリックすると、調査ページが開き、これらの調査の詳細情報を表示できます。

TeamCity は、調査された問題を視覚化するために警察官のアイコンを描画します。このアイコンの上にマウスを置くと、問題に関する詳細情報が表示され、ユーザーは問題を再割り当てしたり、手動で修正済みとしてラベル付けしたりできます。

ユーザーが調査を修正済みとしてマークすると、アイコンの色が緑に変わります。このアイコンは、同じ問題が発生することなく新しい実行が終了するまで表示されたままになります。

問題のステータスを手動で「修正済み」に設定すると、TeamCity ヘッダーのユーザーの調査カウンターは減りますが、問題が引き続き発生する場合、新しいビルドが失敗することを防ぐことはできません。TeamCity でこの問題を無視したい場合は、修正済みとしてラベル付けするのではなく、ミュートします。

TeamCity は、問題調査を自動的に作成し、これらの障害の原因である可能性が最も高いユーザーに割り当てます。これを行うには、調査自動割り当てビルド機能を構成します。

ミュート

ミュートされた問題は、ビルドが正常に終了したことを報告することを妨げない問題です。ミュートされた問題が原因で失敗したビルドは、正常に終了したと表示され、ミュートされた問題の数が表示されます。

ビルドの問題またはテストをミュートすると、解決されると予想される既知の問題を一時的に無視したり、失敗すると予想されるテストを無視したり、ビルドで問題が発生した場合でも後続のステップまたはビルドチェーン構成が実行されるようにしたりできます。

TeamCity は、ミュートされた問題を視覚化するためにスピーカーアイコンを描画します。このアイコンの上にマウスを置くと、この問題に関する詳細情報が表示されます。

アクティブな問題を管理する

ビルド結果ページと問題タブの両方に、ユーザーが問題をミュート、ミュート解除、調査、修正済みとしてマーク、別のユーザーに再割り当てできる UI 要素が表示されます。複数の問題に同じアクションを一度に適用するには、問題タブに移動して必要なエントリを選択します。

調査とミュートを編集する場合、TeamCity では次の設定を指定できます。

• 調査 / ミュート範囲。同じプロジェクト内のすべての構成 (その子サブプロジェクトを含む) に属するビルドでこの問題をミュート / 調査するには、「プロジェクト全体」を選択します。「選択したビルド構成」オプションを使用すると、必要な構成に対してのみ問題をミュート / 調査できます。

• 調査と担当者。ミュートされた問題は、失敗したビルドが成功したように見え、根本的な問題が見えにくくなる可能性があります。そのため、ミュートと調査を組み合わせて、誰も調査していない問題をミュートしたままにしないようにすることをお勧めします。

• 自動ミュート解除 / 解決ポリシー。TeamCity が問題をミュート解除するか、解決済みとしてマークする条件を指定できます。

  • Automatically when fixed — 問題が新しいビルドで解決された場合、TeamCity はそれをミュート解除し、関連する調査を終了します。これは、今後のビルドで問題が再発した場合にチームが迅速に対応できるようにするデフォルトのシナリオです。

    "fixed" の問題は、ステータスが手動で変更された問題 ( 調査セクションを参照)、または新しいビルドで解消された問題です。ブランチとの関係も参照してください。

  • Manually — TeamCity ユーザーのみが、アクティブな調査を閉じてミュートを元に戻すことができます。このモードは、不安定なテストをミュート / 調査する場合に推奨されます。これらのテストは不安定であり、正常に実行されても問題が解決されることは保証されないためです。

  • On a specific date — TeamCity は、指定された日付に調査を終了するか、問題のミュートを解除します。この条件は、チームがすぐに修正できないが、CI ルーチンを実行し続ける必要がある、重大ではない問題に役立ちます。

• 設定を子サブプロジェクトにコピーします。このプロジェクトとその子サブプロジェクトに存在する調査 / ミュートを編集する場合、TeamCity では、更新された設定をこれらのサブプロジェクトに伝播するかどうかを選択できます。そうでない場合、子サブプロジェクトの調査 / ミュートは異なります (たとえば、別のユーザーに割り当てられます)。

  

必須アクセス権

プロジェクト内の調査 / ミュートを管理および表示するには、ユーザーにこのプロジェクトで次の権限が付与されている必要があります。

• ミュートを管理するための「プロジェクト内のミュート / ミュート解除の問題」

• 調査を管理するための「調査の割り当て / 割り当て解除」

• 既存の調査 / ミュートを表示するための「プロジェクトとすべての親プロジェクトを表示」

これらの権限は、デフォルトでプロジェクト管理者とシステム管理者に付与されます。

ブランチとの関係

調査とミュートはブランチ固有のものではありません。問題が調査またはミュートされると、その問題が現れるすべてのブランチに対して調査 / ミュートされます。ただし、TeamCity はブランチ固有のビルドをチェックして、問題が修正されたかどうかを判断します。これは、「修正時に自動的に」ミュート解除 / 調査終了条件の問題の処理方法に影響します。

• 複数のブランチで障害が発生し、そのうちの 1 つがデフォルトのブランチである場合、デフォルトのブランチで障害が解消されると問題は解決されたとみなされます。

• デフォルト以外のアクティブなブランチのみで障害が発生した場合、これらすべてのブランチで障害が解消されると問題は解決されたとみなされます。