GitLab×Renovate でハマった 2 つのポイント

依存関係の更新を自動で検出・提案するツールである Renovate を公式ドキュメントに沿って GitLab 上で利用できるよう設定したところ、次の 2 つの課題に直面しました。

1. ジョブが Error: spawn ENOMEM で落ちる
2. ブランチはできているのに、いつまで経っても Merge Request が出てこない

どちらもインストール手順とは関係なく、「運用を始めてから」気づきがちなポイントだったので、対処法だけに絞ってまとめます。

---

1. Error: spawn ENOMEM が出たら Runner のメモリを疑う

Renovate は Git 操作や依存解析でそれなりにメモリを食います。
GitLab CI ジョブが次のようなログを出してこける場合、

Error: spawn ENOMEM

まず疑うべきは GitLab Runner（docker executor）のメモリ不足です。

/etc/gitlab-runner/config.toml の対象 Runner に、メモリ関連の設定を足します。

[[runners]]
  name = "renovate-runner"
  url = "http://XXXXX:8891"
  token = "<token>"
  executor = "docker"

  [runners.docker]
    image = "alpine:latest"
    oom_kill_disable = true
    shm_size = 536870912  # 512MB
    memory = "3g"         # まずは 2〜3GB 程度から
    memory_swap = "3g"
    volumes = ["/cache"]

ポイントはこの 3 つです。

• memory / memory_swap を明示的に指定する
• shm_size を増やす（デフォルトのままだと足りないことがある）
• oom_kill_disable = true で OOM Kill を避けやすくする

なお、memory と memory_swap を同じ値にすると、Docker の仕様上スワップは使われません（swap = memory_swap - memory が 0 のため）。
「スワップには逃がさず、物理メモリ上限できっちり止めたい」場合は同じ値に、
「多少スワップを許容したい」場合は memory_swap を少しだけ大きな値にするのがおすすめです。

設定を変えたら Runner を再起動します。

sudo systemctl restart gitlab-runner

これで spawn ENOMEM がピタッと止まるケースが多いです。

---

2. ブランチはできるのに Merge Request が出ないときは Concurrent を見る

「Renovate のジョブ自体は成功している」「対象リポジトリにブランチもできている」のに、Merge Request が一向に作成されない場合があります。

そのとき確認したいのが prConcurrentLimit と branchConcurrentLimit です。

renovate.json の例

{
  "extends": ["config:best-practices"],

  "prCreation": "immediate",
  "prConcurrentLimit": 2,
  "branchConcurrentLimit": 4
}

ざっくり言うと：

• prConcurrentLimit
  「同時に開いてよい Merge Request の上限」
• branchConcurrentLimit
  「同時に扱う Renovate 管理ブランチの上限」

どちらかの上限に達していると、
それ以上の更新候補については「この実行では処理されず、次回以降に持ち越し」という挙動になります。

なぜ branchConcurrentLimit を大きめにした方がよいか

branchConcurrentLimit が prConcurrentLimit と同じかそれ以下だと、

• ブランチの同時上限が先に引っかかる
• その実行中は Merge Request 作成まで進まない

といった状態になりやすくなります。

そこで、

• prConcurrentLimit ＜ branchConcurrentLimit

となるように設定しておくのがおすすめです。

具体例

• prConcurrentLimit: 2
• branchConcurrentLimit: 4

こうしておくと、

• 同時に開く Merge Request は 2 件までに抑えつつ
• 裏側では最大 4 本までブランチを仕込んでおける

ため、

• branchConcurrentLimit が頭打ちで、後続の Merge Request 作成が全く進まない

といった事態を避けられます。

実運用でのおすすめ

• 最初は

  • prConcurrentLimit: 1〜2
  • branchConcurrentLimit: その 2 倍くらい（例：2→4、3→6）
    からスタート

• CI やレビュー体制に余裕が出てきたら

  • prConcurrentLimit を少しずつ上げる（2 → 4 → 5 …）
  • その際も 常に prConcurrentLimit ＜ branchConcurrentLimit を維持する

「ブランチは見えるのに Merge Request が生成されない」ときは、この 2 つの設定をセットでチェックすると状況がつかみやすくなります。

---

まとめ

Renovate 自体の導入は一度できてしまえば終わりですが、実際に回し始めてからのトラブルはだいたい次の 2 つでした。

1. spawn ENOMEM

   • Runner のメモリ割り当て（memory / memory_swap / shm_size）を増やす

2. ブランチはできているのに Merge Request が出ない

   • prConcurrentLimit と branchConcurrentLimit を見直す
   • 特に branchConcurrentLimit の上限に達すると後続の Merge Request 作成が実施されない点を理解したうえで、
     prConcurrentLimit ＜ branchConcurrentLimit になるように設定する

どちらも設定ファイルを少し直すだけで解消できるので、同じ症状で悩んでいる方の参考になれば幸いです。