Forgejo Runner の同時実行数を 8 にする

[5ym]

PR 1 本につきワークフローが 2 本(test と claude-review)走るようになり、capacity: 2 では順番待ちが長い(実測で 6 本が 30 分以上詰まった)。

• capacity 2 → 8
• dind のメモリ上限 12Gi → 28Gi。ジョブのコンテナは全部 dind の中で動くので、ここが CI 全体の上限になる
• runner 本体のメモリ上限 1Gi → 2Gi(8 本ぶんのログを同時に流す)

ノードは 44 コア / 46 GiB。いまの使用率は CPU 8% / メモリ 16%(CI 以外の実使用は 8 GiB ほど)なので、28Gi を CI に割いても 10 GiB 残る。CPU は 44 コアあるので 8 本でも余る。重いのは e2e(ブラウザ)くらいで、それが同時に何本も来ることは稀。

**マージすると Runner の Pod が入れ替わる(strategy: Recreate)ので、走っているジョブは落ちる。**キューが空いているときに入れること。

🤖 Generated with Claude Code

https://claude.ai/code/session_01JgGYf5qbjDXYhtzcpLsGvv

[claude]

Claude finished @5ym's task in 1m 20s —— View job

---

レビュー結果

• PR の差分・コンテキストを取得
• apps/forgejo/runner.yaml の変更内容を確認
• リポジトリの規約 (CLAUDE.md 等) を確認(該当ファイル無し。apps/forgejo/README.md の運用メモは確認済み)
• レビュー結果をまとめて投稿

総評

大きな問題は見当たりません。capacity 2→8、dind のメモリ上限 12Gi→28Gi、runner 本体 1Gi→2Gi という変更は PR 本文の説明(ノード 44 コア/46 GiB、CI 以外の実使用 ~8 GiB)と整合しており、各設定値の横にその根拠を残すコメントも追加されていて分かりやすいです。CPU の limit は元々未設定のままで、これは適切です(CPU は余裕があるため burstable のままで問題なし)。

参考までに(ブロッキングではありません)

• 46 - 8(CI 以外)- 28(dind)= 10 GiB という PR 本文の計算は、同じ Pod の runner コンテナ側の 2Gi 上限を加味すると実質の残りは ~8 GiB になります。誤差は小さく、それでも十分な余裕があるので指摘というほどではありません。
• docker-data の emptyDir の sizeLimit: 60Gi(このファイルの下の方、今回は未変更)は capacity=2 のときの想定と思われます。同時実行が 8 本になるとイメージの pull が重なりやすくなるはずなので、運用してみて容量が厳しくなるようなら見直しの余地があるかもしれません。要確認(今回の変更で必ず問題になるとは限らないため)。
• PR 本文にある「マージすると Runner の Pod が入れ替わる(strategy: Recreate)ので、走っているジョブは落ちる」という点はコード上も runner.yaml の strategy: Recreate 設定(変更なし)と一致しており、マージのタイミングに注意という運用上の注意点として妥当です。

テストについては k8s マニフェストの数値変更のみで、リポジトリに該当するユニットテストの仕組みは見当たらず、この種の変更として妥当だと考えます。

Branch: runner-capacity