TeamCity データのクリーンアップ
TeamCity のクリーンアップ機能により、古いビルドデータや不要なビルドデータを自動的に削除できます。
サーバーのクリーンアップ構成は管理 | サーバー管理 | クリーンアップ設定で使用可能です。クリーンアップスケジュールの設定が可能で、一般的なクリーンアップ情報が表示されます。
特定のプロジェクトに関連するクリーンアップルールはプロジェクト設定で設定されます | クリーンアップルール。これらのルールは、どのデータをクリーンアップし、どのデータを保持するかを定義します。これらは、プロジェクトまたはビルド構成に割り当てることができます。
クリーンアップルールを構成して、古いビルドとそのアーティファクトを削除し、データベースとキャッシュから不要なデータを消去してディスク領域を解放し、TeamCity UI からビルドを削除して、TeamCity のワークロードを削減することをお勧めします。
クリーンアップにより、 <TeamCity Data Directory> /system およびデータベースに保存されているデータが削除されます。また、クリーンアップ中に、サーバーはさまざまなメンテナンスタスクを実行します (たとえば、VCS フルパッチキャッシュをリセットします)。
サーバーのクリーンアップ設定
サーバーのクリーンアップ設定は管理 | サーバー管理 | クリーンアップ設定で構成されます。
ビルド履歴のクリーンアップはバックグラウンドプロセスとして実行されます。つまり、サーバーメンテナンスのダウンタイムはありません。
クリーンアップするデータの量によっては、プロセスにかなりの時間がかかり、その間サーバーのパフォーマンスが低下する可能性があります。クリーンアップはオフピーク時間にスケジュールすることをお勧めします。デフォルトでは、TeamCity は毎日 3:00 AM にクリーンアップを開始します。毎日の開始時間を変更したり、カスタム cron 式を設定して必要な頻度でクリーンアップを開始したりできます。
手動でクリーンアップを開始するも可能です。
クリーンアッププロセスの制限時間も指定できます。指定した時間枠内にすべてのデータがパージされない場合、残りのデータは次のクリーンアッププロセス中に削除されます。
クリーンアップを有効にすると、TeamCity はデフォルトでサーバー監査レコードを 1 年間 (365 日間) 保持します。
手動クリーンアップ起動
サーバーのクリーンアップ設定の前回のクリーンアップセクションでは、以下のことが可能です。
以前のサーバークリーンアップの日付と期間に関する情報を確認して、特定のタイミングでクリーンアッププロセスを開始するかどうかを判断します。
今すぐクリーンアップを開始ボタンを使用して、手動でクリーンアップを実行します。
クリーンアップ中に、TeamCity は進行状況を報告します。必要に応じて、クリーンアッププロセスを停止できます。残りのデータは、次のクリーンアップ中に削除されます。
クリーンアップ規則
クリーンアップ規則は、現在のプロジェクト、そのサブプロジェクト、ビルド構成のデータを消去する方法を定義します。
プロジェクト設定のクリーンアップ規則ページでは、現在のプロジェクトとそのビルド構成のクリーンアップルールを表示および管理できます。このプロジェクトにサブプロジェクトがある場合は、オプションでサブプロジェクトのルールも表示できます。
プロジェクトのクリーンアップルールには 2 つのタイプがあります。
基本ルールは、どのデータをいつ削除するかを定義します。それらは設定が簡単で、ほとんどの一般的なクリーンアップのケースに対応しています。各プロジェクトおよびビルド構成に 1 つの基本ルールが割り当てられます。基本ルールの構成方法を読む
ルールを守るは、クリーンアップ中に保存するデータを定義します。それらは非常に柔軟ですが、基本ルールよりも構成に多くの労力がかかります。複数の保持ルールをプロジェクトまたはビルド構成に割り当てることができます。キープルールの構成方法を読む
キープルールはよりきめ細かく、すべてのビルドを特定のタグ(たとえば、release)または特定のブランチで保持するなどのケースをカバーできます。キープルールを使用するには、さまざまな種類のビルドとそのデータをよりよく理解する必要がありますが、柔軟性も向上します。基本ルールを設定して一般的なクリーンアップシナリオを構成し、複数の保持ルールを追加して、保持する正確なデータを調整するか、保持ルールのみに依存することができます。
クリーンアップ中に、TeamCity はベースルールとキープルールを分析および結合して、保存および削除するデータの範囲を決定します。
プロジェクトに割り当てられたクリーンアップルールは、そのすべてのサブプロジェクトとビルド構成によって継承されますが、独自のルールによってオーバーライドできます。次のダイアグラムは、サンプルプロジェクト A 全体にルールがどのように伝播するかを示しています。

オーバーライドされたルールは、親プロジェクトの階層内で最も近い元の定義にいつでもリセットできます。
基本ルール
単一の基本ルールが各プロジェクトまたはビルド構成に割り当てられます。基本ルールを使用すると、保存するビルドの成功数、および / またはビルドを履歴に保持する期間を定義できます。
基本ルールでは、次のクリーンアップレベルを使用できます。
アーティファクト : ビルドログを含むすべてのデータが保存され、非表示のアーティファクトも保存されます。
ヒストリー : 統計チャートに表示されるビルド統計値を除くすべてのビルドデータが削除されます。
すべて : TeamCity にはビルドデータが残っていません。
各レベルには、その上のリストが含まれます。
デフォルトでは、すべてが永久に保持されます。カスタム設定を選択すると、上記の各レベルで次を指定できます。
日数 :
指定された日数より古いビルドは、指定されたレベルでクリーニングされます。開始点は、現在の日付ではなく、最後に成功したビルドビルドの日付です。1 日は、暦日ではなく、24 時間に相当します。成功したビルドの数 :
最後に一致した成功したビルドより古いビルドのみが、指定されたレベルでクリーンアップされます(保存された成功したビルド間のすべての失敗したビルドが保持されます)。
両方の条件が指定されている場合、適用されたすべてのルールに従ってクリーンアップする必要があり、保持ルールによって保持されないビルドのみが実際に削除されます。TeamCity は、各ルールに従って保存する最も古いビルドを見つけ、見つかった 2 つのビルドのうち最も古いものよりも古いすべてのビルドをクリーンアップします。
レベルに対して成功したビルドの数制限が指定されているが、履歴に成功したビルドがない場合、TeamCity はこのレベルのデータをクリーンアップしないことに注意してください。
アーティファクトレベルでは、アーティファクト名のパターンも指定できます。指定されたパターンに一致するアーティファクトは、クリーンアップに含まれるか、クリーンアップから除外されます。Ant のようなパターン(英語)の後に改改行コードのルールを使用します。例:
名前の一部として
fileを使用してアーティファクトをクリーンアップするには、構文+:**/file*.*を使用します。名前の一部として
fileを持つ*.jarアーティファクトをクリーンアップから除外するには、-:**/file*.jarを使用します。
依存関係ビルドの基本ルールの動作
基本ルールの依存関係ブロックでは、依存関係ビルド構成のビルドアーティファクトのクリーンアップ動作オプションを選択することもできます。TeamCity は、他のビルドでスナップショット依存関係として使用されるビルドを常に保持します。これらのビルドは、依存ビルドが削除されるまで、クリーンアップ手順によってビルド履歴から削除されません。これらのビルドのアーティファクトは、以下のオプションに基づいて削除できます。
TeamCity は、アーティファクトの依存関係によって他のビルドで使用されるビルドとそのアーティファクトをオプションで保存できます。次のオプションが利用可能です。
デフォルトを使用するは、デフォルトのクリーンアップルールで構成されたオプションを使用します。
クリーンアップを防ぐは、現在のビルド構成のビルドのアーティファクトまたはスナップショットの依存関係のソースとして使用されたビルド(およびそのアーティファクト)を保護します。
クリーンアップを妨げない (デフォルト) では、依存関係ビルドのクリーンアップ関連の処理で、現在のビルド構成のビルドで使用されているという事実が無視されます。依存関係ビルドとアーティファクトはクリーンアップされます。このオプションを選択した場合でも、クリーンアップによってスナップショット依存関係ビルドのビルド履歴とログは削除されないことに注意してください。
例: 依存ビルド構成 A は B にアーティファクト依存関係があります。クリーンアップを防ぐオプションが A に使用される場合、A のビルドのアーティファクトを提供する B のビルドは、ビルドのクリーニング中に処理されないため、ビルドとそのアーティファクト保存されます。
機能ブランチを使用したビルド構成の基本ルールの動作
ビルド構成に複数のブランチからのビルドがある場合、基本クリーンアップルールを適用する前に、TeamCity はこの構成のビルド履歴を複数のグループに分割します。TeamCity はアクティブなブランチごとに 1 つのグループを作成し、非アクティブなブランチからのすべてのビルドに対して 1 つのグループを作成します。次に、基本クリーンアップルールが各グループに個別に適用されます。
パーソナルビルドの基本ルールの動作
ベースクリーンアップルールは、非個人用ビルドと個人用ビルドに別々に適用されます。つまり、3 つの成功したビルドを保持するルールがある場合、3 つの非個人ビルドと 3 つの個人ビルドが(上記の各ブランチグループで)保存されます。
ビルド構成テンプレートの基本ルール
TeamCity 2019.2 以前は、ビルド構成テンプレートに基本ルールを割り当てることが可能でした。互換性のために、ビルド構成テンプレートの既存のクリーンアップルールはすべてそのままで、クリーンアップ規則ページでアクセスできます。
ルールを守る
キープルールは、クリーンアップ中に保存する特定のデータを定義します。複数の保持ルールをプロジェクトまたはビルド構成に割り当てることができます。
各保持ルールでは、次の設定を構成できます。
保存するデータを作成する : 履歴、アーティファクト、ログ、統計、すべて。
依存関係内のアーティファクトを保持するかどうか。このオプションは、依存関係ビルド構成のビルドもクリーンアップするかどうかを制御します。このオプションを有効にすると、このルールによって一部のビルドが保持される場合、その依存関係ビルドのすべてのアーティファクトも保持されます。このオプションは、基本ルールの依存関係オプションと同様に機能します。
ビルド範囲 : ルールの影響を受ける時間間隔または最後のビルドの数。
オプションで、保存されたビルドをステータス、タグ、ブランチでフィルタリングできます (パターンマッチングによるブランチフィルターがサポートされています)。ルールを個人用ビルドまたは非個人用ビルドのみに制限することもできます。
制限を、一致する各ブランチに個別に適用するか、選択したブランチのすべてのビルドに単一のセットとして適用する必要があるかを選択します。
この条件は、影響を受けるビルド構成ごとに 1 回適用されます。フィルターにブランチが指定されていない場合は、次のように適用されます。ビルド構成内の各ブランチまたはすべてのビルド構成ブランチにセットとして適用します。
サンプル: 最新のビルド 10 件の統計を保持することを選択し、このルールに対して 2 つのブランチを選択した場合は、「すべて選択済み」を選択して、選択した両方のブランチ間で最新のビルド 10 件を保持するか、「選択された各ブランチ」を選択して、最新のビルド 20 件 (ブランチごとに 10 件) を保持することができます。
TeamCity は、次の順序で保持ルールを処理します。
影響を受けるプロジェクトまたはビルド構成のビルドをフィルターします。
ルールをすべての選択されたブランチに適用するか、選択された各ブランチのビルドに個別に適用するかを決定します ( 説明を参照)。
指定された範囲内でのみビルドを保持します。
保存するビルドデータの種類を決定します。
依存関係ビルドのアーティファクトを保持する必要があるかどうかを決定します。
ルールの保持動作に関する注意事項:
複数のタグを入力すると、これらのタグのいずれかでマークされたすべてのビルドにルールが適用されます。
すべての「からの日数」範囲オプションでは、TeamCity は特定の日付の小数時間を考慮せず、選択した日(深夜から 11:59 PM まで)から開始日までの時間間隔で開始したビルドのみにルールを適用します。影響を受ける範囲(選択された日から設定された日数の制限を引いたもの)。
削除されたビルド構成のクリーンアップ
プロジェクトまたはビルド構成が削除されると、対応するビルドデータはクリーンアップ中に削除されますが、これは削除から 5 日 (432,000 秒) が経過した場合に限られます。
タイムアウトを変更するには、teamcity.deletedEntities.cleanupTimeout 内部プロパティを必要な秒数に設定して、データを削除から保護します。
クリーンアップ診断
TeamCity がクリーンアップを実行すると、一部の古いビルドが保持される可能性があり、現在のクリーンアップまたは保持ルールと一致しないように見える場合があります。例: 依存関係で参照されるビルドは保持されます。
ビルドが削除されなかった理由を調査するには、ビルドに diagnostics:cleanup タグのラベルを付けます。クリーンアップ中に、TeamCity はタグ付けされたすべてのビルドを識別し、これらのビルドが保持された理由を説明する詳細なレポートを生成します。このレポートは、ビルドアーティファクトとして非表示の .teamcity/cleanup/ ディレクトリに保存されます。
レポートには次の情報が含まれています。
一般的なビルドとサーバーの詳細: ビルド ID、サーバーバージョン、クリーンアップ開始時刻。
適用可能な各ルールの概要: 現在のビルドと一致するかどうか、一致しない場合はその理由。
関連するルールに基づいて保持する必要があるビルドコンポーネントのリスト。
現在のビルドに依存するビルドの概要(存在する場合)。
レポートを生成した後、TeamCity はビルドから diagnostics:cleanup タグを削除します。
関連ページ:
プロジェクト管理者ガイド
このセクションでは、プロジェクト管理に焦点を当てます。TeamCity プロジェクトとビルド構成の作成、ビルドステップの設定、依存関係チェーンの構成などについて説明します。基本的な TeamCity ワークフロー:次のダイアグラムは、基本的な TeamCity ワークフローを示しています。TeamCity サーバーはリポジトリの変更を検出しました。サーバーはこの変更をデータベースに書き込みます。ビルド構成に添付されたトリガーは、データベース内の関連する変更を検出し、ビルドを開始します。トリガー...
TeamCity データディレクトリ
TeamCity データディレクトリは、TeamCity サーバーが構成、ビルド結果、現在の操作ファイルを保存するために使用するファイルシステム上のディレクトリです。このディレクトリは、すべての構成設定の 1 次ストレージであり、TeamCity のインストールに不可欠なデータを保持します。ビルド履歴、ユーザーとそのデータ、その他のデータはデータベースに保存されます。ディレクトリとデータベースに保存されるデータの説明については、バックアップに関する注意事項を参照してください。このドキュメントや他...
ビルドの主なアクション
この記事では、TeamCity のビルドに適用できるアクションについて説明します。ビルド実行:TeamCity では、ビルドを実行できます。自動的に、さまざまなビルドトリガーを使用します。手動で、オンデマンド。ビルドを手動で実行するには、画面の右上隅にある実行をクリックします。このアクションは、編集モードと表示モードモードの両方で使用できます。特定のビルド構成で実行ボタンが表示されない場合は、そのビルド構成でビルドを開始するための権限が不足していることを意味します。実行ボタンの横にあるコンテキ...
ビルド構成の依存関係
実際の CI/CD パイプラインでは、多くの場合、複数のスタンドアロンステージが組み合わされます。たとえば、「ビルド」、「テスト」、「ステージングへのデプロイ」構成 (またはジョブ) は、独立して実行することも、順番に実行することもできます。TeamCity は、これらのスタンドアロンエンティティ間の関係を作成するための複数のオプションを提供します。ビルドチェーンビルドチェーンは、スナップショット依存関係を使用して相互接続された従来の TeamCity 構成のコレクションです。スナップショットの...
プロジェクトの作成と編集
TeamCity では、実際のビルドタスクはビルド構成とパイプラインによって実行されます。ただし、どちらもプロジェクト内に配置する必要があります。このトピックでは、プロジェクトを作成するさまざまな方法を説明します。ルートプロジェクトと設定の継承:始める前に、すべての TeamCity サーバーには、ルートプロジェクトと呼ばれる削除不可能な組み込みプロジェクトが含まれていることにご注意ください。すべての新しいプロジェクトはこのプロジェクトの子として作成されますが、ビルド構成やパイプラインを直接ホ...
統計チャート
プロジェクトの状況や個々のビルド構成を長期にわたって追跡できるようにするために、TeamCity はすべての履歴にわたって統計データを収集し、それをビジュアルチャートとして表示します。統計チャートは次のカテゴリに分類できます。プロジェクトレベルの統計はプロジェクトホーム | 統計タブで利用可能です。構成レベルの統計を作成するは、ビルド構成ホームページ | 統計タブで利用できます。統計タブで選択した統計レベルに関係なく、次のことができます。ブランチフィルターを使用して、指定されたブランチからの結果の...