症状：Jenkins Mac Agentがディスク不足でオフラインになり、Workspaceを消しても空き容量が戻らない。
最速解決：全体を削除せず、Remote FS、ユーザー領域、テンポラリ、アーカイブを分けて調査し、再構築性とリリース価値に応じて処理してください。

この方法は、Jenkins Mac Agentの日常運用、iOS CI/CDの安定化、Macノードの増設判断を担当する人向けです。単発の空き容量回復ではなく、同じ障害を繰り返さない保有ルールまで決めたい場合に適しています。

まずJenkins Mac Agentのディスククリーンアップ対象を分ける

典型的な失敗は、ディスク監視でノードがオフラインになった直後に、最大のWorkspaceを削除することです。ところが実際には、DerivedData、シミュレーター、依存関係キャッシュ、アーカイブが別の場所で増えており、削除後も容量不足が続くことがあります。

JenkinsはノードのRemote FSや一時領域のディスク状態を監視できます。まず管理画面の表示とMac側の実使用量を照合し、Finderの分類だけで削除範囲を決めないでください。APFSでは論理的なファイルサイズ、スナップショット、解放可能領域の表示が一致しない場合があるためです。確認方法はJenkins公式のノード管理ドキュメントを基準にします。

確認領域 先に確認する内容 直ちに削除してよいか
Jenkins Remote FS 現在実行中のWorkspace、後継ジョブ、並行実行用の別名ディレクトリ 状態確認なしの一括削除は不可
ユーザー領域 DerivedData、Swift Package Manager、CocoaPods、Homebrewなど 再取得経路を確認してから
一時領域 途中終了したビルドや展開途中のファイル 使用中プロセスを確認してから
アーカイブ領域 .xcarchive、dSYM、公開版と関連する証跡 リリース担当者の承認が必要

最小限の棚卸しでは、次のように大きいディレクトリと更新時刻を確認します。実行前に対象パスを変数へ固定し、ルート全体へ機械的に適用しないでください。

du -xhd 1 "$JENKINS_HOME" 2>/dev/null | sort -h
find "$WORKSPACE_ROOT" -type f -mtime +30 -print
df -h /

duの結果だけで削除対象を確定してはいけません。プロセスが開いているファイル、次のビルドが参照するWorkspace、macOSのスナップショットを別途確認します。

次にWorkspaceの増加原因とJenkinsの保持設定を確認する

Jenkins Workspaceはビルド後に自動削除できるか

可能ですが、ジョブの種類と再実行要件を確認してから設定します。PipelineではWorkspaceが割り当てられ、並行タスクでは後尾付きの別ディレクトリが作られることがあります。多分岐ジョブでは、削除済みブランチに関連するWorkspaceが残ることもあるため、実際のパスをログで確認してください。

PipelineのWorkspace仕様と、多分岐ジョブの保持設定を確認し、次のいずれかを選びます。

  • 再現可能な通常ビルド：cleanWsをビルド後処理に組み込みます。Workspace Cleanup Pluginの公式手順に合わせ、失敗時に診断用ファイルを残すか決めます。
  • 再現に時間がかかるビルド：直後に全削除せず、ジョブの保持期間と容量上限を組み合わせます。
  • 署名やリリースを含むビルド：公開ログ、アーカイブ、dSYMをWorkspaceと同じルールで消さないようにします。
  • 並行実行中のジョブ：ノードを一時的に新規受付停止にし、実行中のパスを確認してから保守します。

注意：Jenkinsの状態を確認せず、rm -rfでAgent上のWorkspaceを一括削除しないでください。ソースの再取得だけで戻らず、途中生成物、ログ、署名工程の診断材料を失う可能性があります。

Xcodeの生成物を再構築性と証跡価値で分類する

XcodeのDerivedDataとシミュレーターは安全に消せるか

DerivedDataは通常、ソースと依存関係から再生成できる領域です。ただし削除後は再コンパイルが必要になり、依存関係を取得できない閉域環境では復旧条件が変わります。シミュレーターのデバイスデータも、テスト状態や診断ログを保持している場合は先に確認してください。

一方、Simulator RuntimeやXcodeのプラットフォームコンポーネントは、単なるビルドキャッシュではありません。再ダウンロードやインポートが必要になるため、対象Xcodeで利用可能な取得経路を確認します。追加コンポーネントの管理方法は、AppleのXcodeコンポーネント管理資料を参照してください。

データ種別 再構築・再取得 消去判断
DerivedData 通常は再ビルド 空き容量と復旧時間を確認して候補にする
シミュレーターのデバイスデータ テスト環境の再作成が必要 実行中テストと診断情報を確認する
Simulator Runtime 取得または導入が必要 対応するXcodeと復旧経路を先に確認する
Xcode Archives リリース証跡として利用 保持期間をリリース責任者が決める
dSYM クラッシュ解析に必要 公開版との対応を確認するまで保持する

ArchivesとdSYMは、空き容量だけを理由に削除しないでください。Appleはデバッグ情報とdSYMをアプリの解析に利用する資料を公開しています。dSYMの扱いに関するAppleの説明と、配布・リリース記録の要件を確認したうえで、外部の制作用ストレージへ移すか判断します。

依存関係キャッシュと重複コピーの責任者を決める

Swift Package Manager、CocoaPods、Homebrew、Git LFS、プロジェクト独自キャッシュは、Workspaceとユーザー領域の両方に存在することがあります。さらにJenkins Controller、Mac Agent、成果物保管先に同じデータが複製されていると、Agentだけを掃除しても全体の容量問題は解決しません。

次の4項目で資産表を作ると、保持期間を一律に決めずに済みます。

  • データ所有者：開発チーム、リリース担当、IT運用のどこが管理するか
  • 再構築性：ネットワーク、認証、外部レジストリがなくても戻せるか
  • 再利用範囲：単一ジョブだけか、複数プロジェクトで共有するか
  • 削除条件：容量上限、最終利用時刻、世代数、リリース完了のどれをトリガーにするか

条件分岐で清掃方法を決める

  • 現在のジョブが使用中、または署名工程が参照中なら、削除せずノードを新規受付停止にして保守時間を確保します。
  • 再取得経路が確認済みで、リリース証跡に該当しないなら、DerivedDataや期限切れキャッシュを候補にします。
  • 同じキャッシュが複数保管先にあり、復元テスト済みなら、Agent側の重複コピーを減らします。
  • 削除後も日次の増加量が復旧余力を上回るなら、清掃を強化するのではなく、並行数を減らし、ノード分割または容量追加へ進みます。
  • 署名、公開、障害解析を同じMacで処理しているなら、通常ビルド用ノードと署名ノードを分離します。

削除後は署名流水線とノード復旧を検証する

清掃前に、対象パス、占用プロセス、実行中ジョブ、削除担当者、復元方法を記録します。必要であればノードを一時的にオフライン化し、保守中に新しいビルドが割り当てられない状態にします。Jenkinsの管理機能全体は公式の管理ドキュメントで確認できます。

削除後の受入順序は、空き容量の数字ではなく、流水線の成功で判定します。

  1. Mac Agentを再接続し、Remote FSの表示を確認します。
  2. ソースコードを新しいWorkspaceへ取得します。
  3. 依存関係を復元し、対象Xcodeとプラットフォームが利用できるか確認します。
  4. 通常ビルドとテストを実行します。
  5. 署名、アーカイブ、配布用の工程を検証します。
  6. ノードを再起動し、監視が正常に復帰するか確認します。
  7. 次の複数回のビルドで、容量増加とキュー滞留を記録します。

署名証明書や秘密鍵を一般的なキャッシュ削除スクリプトの対象に含めないでください。Keychain、アーカイブ、ログを削除すると、ビルドが失敗するだけでなく、障害の再現や公開版との照合ができなくなる場合があります。

清掃で足りない場合はMacノードを増やす

Mac構築機が繰り返しディスク満杯になる場合、原因は清掃不足とは限りません。単一ノードへの並行数が多い、Xcode環境を複数保持している、成果物をAgentに置き続けている、または1回のビルドが作るピーク領域に対してストレージが小さい可能性があります。

容量表には、少なくとも次を記録します。

  • ビルド開始前と終了後の空き容量
  • 1回のビルドで増えた最大値
  • 日次の純増量
  • 清掃の実施頻度
  • キャッシュ再構築に要した企業内の記録時間
  • ディスク警告、受付停止、ノード離脱の回数
  • ビルドキューと署名ジョブの待機状況

警告、受付停止、手動介入の3段階を設定する場合も、固定の容量値を他社から流用しないでください。自社の最大ビルドピーク、Xcodeコンポーネントの導入余地、障害復旧に必要な余白から算出します。

容量追加を検討するなら、固定Macを自社で購入する方法と、必要な期間だけMACCOMEの遠隔Macを構築ノードとして使う方法を分けて評価してください。自社購入は長期の安定負荷や物理接続に向きますが、初期調達、保守、故障交換、遊休期間の費用を抱えます。既存のMacを増設するだけでは、署名ノードと通常ビルドの競合も残ります。

反対に、短期のリリース増加、検証用Xcode環境、キュー解消が目的なら、遠隔Macを試験ノードとして追加し、実際のビルド時間、失敗率、ディスク増加を比較できます。チーム向けのMac運用を検討する場合は、MACCOMEのMac環境案内から利用条件を確認し、購入とレンタルの差分を容量表に反映してください。物理ポートや長期固定負荷が必須なら、Mac miniの導入選択肢も比較対象に残すべきです。

清掃しても受付停止が頻発するなら、現行構成は「清掃戦略の問題」ではなく「容量と役割分担の問題」です。通常ビルド、テスト、署名、公開を分離し、固定ノードまたは必要時だけ追加するMACCOMEの遠隔Macを、実データで試験する方が、削除範囲を広げ続けるより安全です。まず今回の棚卸し結果を容量表に記録し、次の増加量と流水線の復旧結果を確認してから増設を決めてください。