Skip to content
Latchkey

アーティファクトの保持期間とは?

アーティファクトの保持期間とは、CI がアップロードされたアーティファクトを自動的に削除するまでどれだけの期間保持するかを決めるポリシーです。

アーティファクトはストレージを消費し、そのほとんどは短い期間だけ有用です。保持ポリシーはそれらに有効期限を設け、古い build の出力やレポートが永遠に積み上がらないようにします。保持を調整することで、デバッグのしやすさとストレージコストのバランスをとります。

なぜ保持が存在するのか

活発なリポジトリは週に数千のアーティファクトを生成します。それらすべてを無期限に保持するのは高コストで、ほとんど役に立ちません - 先月のテストログが必要になることはまずありません。保持は、設定した期間の後にそれらを自動的に削除します。

保持期間の選び方

  • 短い(1-7 日): 一時的な build の出力とほとんどのレポート向け。
  • より長い: rollback する必要があるかもしれない release アーティファクト向け。
  • 最も長い: 監査やコンプライアンスの理由で保持するもの向け。

小さな例

ノイズの多いデバッグログのアーティファクトに retention-days: 5 を設定し、release バイナリはデフォルトの 90 日のままにすると、rollback する可能性のあるものは残しつつ、誰も読まない一時的なログの保管に費用を払わずに済みます。

設定方法

ほとんどのプラットフォームは、アップロードごとの上書きを伴うデフォルトの保持期間(多くの場合 90 日)を設定します。ノイズの多い job のデフォルトを下げるのは手軽なストレージコストの節約になり、release 向けに引き上げると rollback の対象を保てます。

保持 vs 永続ストレージ

保持は短命な CI アーティファクト向けです。長期的に保持しなければならないもの - リリース済みバイナリ、署名済みイメージ - は、CI のアーティファクトストレージではなく、独自のライフサイクルポリシーを持つ本物のアーティファクト registry や object store に置くべきです。

重要なポイント

  • 保持とは、CI がアーティファクトを削除するまで保持する期間のことです。
  • 短い期間はストレージコストを削減し、長い期間は rollback や監査に役立ちます。
  • 長期的に保持すべきものは、CI のアーティファクトストレージではなく registry に置くべきです。

関連ガイド