プロジェクト

全般

プロフィール

機能 #374

完了

CI: ブランチ別キャッシュ堆積によるランナーディスク枯渇の恒久対処

機能 #374: CI: ブランチ別キャッシュ堆積によるランナーディスク枯渇の恒久対処

エージェント ちゃん さんが14日前に追加. 14日前に更新.

ステータス:
完了
優先度:
通常
担当者:
対象バージョン:
開始日:
2026/06/22
期日:
進捗率:

100%

予定工数:

説明

背景

#355 (MR !17) の CI で test ジョブが15分以上「Compiling ferrhythm-audio」で停止し、no space left on device で job system failure。調査の結果、原因はコードではなく CI キャッシュがブランチ別キー.gitlab-ci.ymlcache.key: "...-$CI_COMMIT_REF_SLUG")で堆積し、GitLab docker executor の孤児ボリュームが 69個 / 113.3GB まで膨張してランナーホスト(共有・他リポと兼用)のディスクを枯渇させたこと。clippy は解析のみ(65秒)で通るが、cargo test はフルコード生成+リンクを通常+--all-features の2回行い target/(≒2.5GB) を生成・保存するため、満杯近いホストを押し切った。

暫定対処(対応済み)

  • 孤児ボリュームを手動回収(docker volume prune 等、ディスク使用率を14%へ回復)。
  • VPS に安全な定期回収 cron を設置: /usr/local/sbin/docker-gc.sh#!/bin/shset -eu)+ /etc/cron.d/docker-gc(6時間ごと)。7日以内のイメージ/ビルドキャッシュは温存、ディスク使用率70%超のときだけ docker volume prune を発動。稼働中の redmine/postgres/uptime-kuma は全てバインドマウント/home/izuna/...)のため prune 対象外=データ不可侵。

恒久対処(本チケットのスコープ)

発生源を .gitlab-ci.yml / workspace 設定で断つ:

  1. キャッシュキーをブランチ別→共有化cache.key.files: [Cargo.lock](必要なら Cargo.toml も)+ fallback_keys で develop のキャッシュを継承。ブランチ毎の新規キャッシュ生成を抑制しウォームスタート化(毎回コールド全ビルドの解消)。
  2. target/ の圧縮。ルート Cargo.toml[profile.dev] / [profile.test]debug = "line-tables-only"(or 0)を追加。テストバイナリ18〜27MB×2の主因=デバッグ情報を削減し target/ を大幅縮小。
  3. (任意)2パス/ピーク資源の見直し。test ジョブの cargo test --workspace(通常)+--all-features の二重ビルドについて、target/ キャッシュの policy: pull 化や CARGO_BUILD_JOBS でピークメモリ/ディスクを抑制。

検証

  • MR パイプラインで fmt/clippy/test が緑、かつキャッシュ再利用でビルド時間が短縮されること(コールド→ウォーム)。
  • 連続 MR でランナーのボリューム/ディスクが再膨張しないこと(cron と併せて二重防御)。

担当

CI 設定変更(.gitlab-ci.yml + ルート Cargo.toml の profile 追記)。Codex 委譲可(source-only)。

参考

親フェーズ無し(CI 基盤の保守)。#355 とは独立。

エージェント ちゃん さんが14日前に更新 操作 #2

  • ステータス未着手 から 実装中 に変更
  • 進捗率0 から 10 に変更

実装に着手しました。

  • ブランチ: feature/374-ci-cache-disk
  • 対応方針: キャッシュキーをブランチ別→Cargo.lock ベースの共有キー+fallback化し、ルート Cargo.toml[profile.dev]debug = "line-tables-only" を追加して target/ を縮小、ランナーディスク枯渇を発生源で断つ。

エージェント ちゃん さんが14日前に更新 操作 #3

  • ステータス実装中 から 完了 に変更
  • 進捗率10 から 100 に変更

対応が完了しました。

概要

CI キャッシュキーがブランチ別($CI_COMMIT_REF_SLUG)だったため、ブランチ毎に ~2.5GB の target/ キャッシュが乱立し共有ランナーのディスクを枯渇させていた問題を、.gitlab-ci.yml / ルート Cargo.toml で発生源から恒久対処した。

変更点

  • キャッシュキーの共有化 (.gitlab-ci.yml default.cache): ブランチ別キー → key.files: [Cargo.lock] + prefix の共有キーに変更し fallback_keys を追加。同一 Cargo.lock のブランチは develop のウォームキャッシュを共有。影響は継承ジョブ clippy/test のみ(fmt/no-op/package/release/notifycache: {} 上書きで無影響)。
  • target/ の縮小 (ルート Cargo.toml): [profile.dev]debug = "line-tables-only" を追加。テストバイナリのデバッグ情報(target/ 肥大の主因)を削減。profile.testdev を継承。backtrace の行情報は温存。
  • 任意項目(#2: policy: pull / CARGO_BUILD_JOBS)は最小変更を優先し意図的に見送り(上記 2 点+既設 cron で二重防御が成立)。
  • 変更ファイル: .gitlab-ci.yml / Cargo.toml の 2 件(+18 / -1)。

テスト

  • cargo check --workspace --all-targets : 成功(exit 0、新 [profile.dev] で全クレートコンパイル成功)
  • cargo metadata : 成功(マニフェスト/profile 受理)
  • GitLab CI lint (validate_ci_lint) : valid=true(errors/warnings なし)
  • ※ CI 設定変更のため単体テスト対象外。ランナー上のウォームキャッシュ再利用・ボリューム非膍張は継続 MR で要経過観察。

関連 MR

  • !18 (feature/374-ci-cache-disk → develop)

他の形式にエクスポート: PDF Atom