GitLab CI/CD artifacts 有効期限問題、3つの解決策比較

Last updated at 2025-04-13Posted at 2025-04-13

回避策の比較と選択

本記事では、GitLab CI/CDのartifacts:expire_inで変数が使えない問題に対する3つの回避策（別記事で解説）を比較検討し、最適な選択肢を提示します。

比較項目	rules によるジョブ分割	API クリーンアップジョブ	保存専用ジョブ
概要	ブランチ毎に異なるexpire_inを持つジョブを定義	APIで条件に合う古いArtifactsを定期削除	Artifactsを目的のexpire_inで再保存するジョブ
実装の容易さ	中〜高 (比較的容易)	低 (API知識、スクリプト実装、Token管理が必要)	中 (YAML構造とneedsの理解が必要)
YAMLの複雑さ/冗長性	中〜高 (ジョブが増え、共通化しないと冗長)	低 (YAML自体はシンプル、複雑さはスクリプトへ)	中 (ジョブ数は増えるが、役割は明確)
パイプライン実行時間への影響	小 (ジョブ数は増えるが並列実行可能)	ほぼ無 (別スケジュール実行の場合) / 小 (同パイプラインの場合)	中 (ArtifactsのDL/ULオーバーヘッドあり)
柔軟性/拡張性	中 (YAMLの範囲内での制御)	高 (スクリプトで自由な条件設定が可能)	中 (保存期間ポリシーを分離できる)
管理コスト	低〜中 (YAMLが複雑化すると管理コスト増)	高 (スクリプトとTokenのメンテが必要)	中 (ジョブ構成の理解が必要)
前提条件/依存関係	特になし	API Token (適切な権限付与)、実行環境(curl等)	needsまたはdependenciesの利用

Kepner-Tregoe法のデシジョン分析を用いて、客観的な基準で選択肢を評価します。

目的: ブランチ毎の Artifacts 有効期限を管理するための最適な回避策を選定する

選択肢:

評価基準:

必須要件 (MUSTs): これを満たさない選択肢は除外
- ブランチ/条件に応じて異なる有効期限を実現できるか？
  - A: Yes / B: Yes / C: Yes (→ 全ての選択肢が必須要件を満たす)
希望要件 (WANTs): 重要度に応じて重み付け (10点満点)、各選択肢を評価 (10点満点)

希望要件 (WANTs)	重み (W)	A: ジョブ分割 (スコア S / 重み付け後スコア W*S)	B: API クリーンアップ (スコア S / 重み付け後スコア W*S)	C: 保存専用ジョブ (スコア S / 重み付け後スコア W*S)	備考 (評価理由など)
1. 実装が容易	8	8 / 64	3 / 24	6 / 48	AはYAMLのみ。BはAPI実装難。CはYAML構造理解。
2. YAML がシンプル/冗長でない	7	6 / 42	8 / 56	5 / 35	Aは冗長化リスク。Bは複雑さをスクリプトへ。Cはジョブ増。
3. 管理が容易 (メンテコスト低)	9	7 / 63	4 / 36	6 / 54	Bはスクリプト/Token管理負担大。A,CはYAML依存。
4. パイプライン実行速度への影響小	6	9 / 54	10 / 60	7 / 42	Bは非同期なら影響無。CはDL/UL時間。Aはジョブ増だが並列可。
5. 特別な権限/ツールが不要	5	10 / 50	3 / 15	10 / 50	BはAPI Tokenが必要。A,Cは基本的に不要。
6. 柔軟性/拡張性が高い	7	6 / 42	10 / 70	7 / 49	Bが最も柔軟。Cはポリシー分離。AはYAMLの範囲。
合計スコア		295	261	278

分析結果:

上記の重み付けとスコアリングに基づくと、選択肢 A (ジョブ分割) が最も高い合計スコア (295) となりました。これは、実装や管理の容易さ、特別な権限が不要な点が評価された結果です。

選択肢 C (保存専用ジョブ) が次点 (278) で、ポリシー分離のメリットがありつつも、やや複雑さとオーバーヘッドが考慮されました。

選択肢 B (API クリーンアップ) は、柔軟性が非常に高いものの、実装と管理のコスト、API Token の必要性が大きく影響し、スコアが最も低く (261) なりました。

注意点:

この KT デシジョン分析の結果は、設定した「希望要件」とその「重み付け」に依存します。実際のプロジェクトでどの回避策を採用するかは、プロジェクト固有の要件や優先順位に合わせて、重み付けや評価を調整した上で判断することが重要です。

どの方法を選択すべきか: