Dependabot¶

Dependabot は GitHub が用意してる、依存パッケージを自動で最新に保つ仕組み。依存パッケージに新しいバージョンが出たり、既知の脆弱性が見つかったりすると、 Dependabot がバージョンを上げる Pull Request (PR) を勝手に作ってくれる。

まずは、バージョンアップデート（version updates）について。依存パッケージに新しいバージョンが出たら PR を作ってくれる。 .github/dependabot.yml を置くと有効になる: cf. About Dependabot version updates

Info

uv を使ってる前提で。あと、 pytest も使ってないと導入してもアップデートを適用しづらいかも。

Full Stack FastAPI Template の設定例

Full Stack FastAPI Template の dependabot.yml は、かなり参考になる。

バージョンアップデートの有効化（dependabot.yml）¶

リポジトリに下のような .github/dependabot.yml を置いて push すると、バージョンアップデートが有効になる。

Dependabot が pyproject.toml と uv.lock を直接読んで依存パッケージを上げるよう PR を勝手に作ってくれる: cf. Using uv with Dependabot

.github/dependabot.yml

version: 2

updates:
  # Python dependencies managed by uv
  - package-ecosystem: "uv"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7
    groups:
      python-packages:
        patterns:
          - "*"

  # GitHub Actions workflows (uses: actions/checkout@v6 etc.)
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7
    groups:
      github-actions:
        patterns:
          - "*"

package-ecosystem … 監視するエコシステム。 uv プロジェクトは "uv"。 GitHub Actions のワークフローで使ってる actions/checkout@v6 のような uses: も更新したいので "github-actions" も書いておくといい: cf. Supported ecosystems
directory … 対象ファイル（ pyproject.toml やワークフロー）がある場所。リポジトリ直下なら "/"。
schedule.interval … チェックする頻度。 "daily" / "weekly" / "monthly" から選べる。

interval ごとのタイミング

daily は平日（月〜金）に毎日、 weekly はデフォルトで月曜、 monthly は毎月1日に走る。時刻は指定しなければリポジトリごとにランダムに割り当てられる（ schedule.time と schedule.timezone で固定もできる）: cf. schedule - Dependabot options reference
cooldown.default-days … 新しいリリースが出てから指定日数（ここでは7日）は更新を待つ。出たばかりで不安定かもしれないバージョンをすぐ取りに行かないようにできる。

uv の exclude-newer を使ってるなら日数を合わせる

uv 側で exclude-newer（指定日より新しいリリースを使わない設定。書く場所は dependabot.yml ではなく pyproject.toml などの uv のほう）を使ってるなら、その日数を cooldown.default-days と揃えておく。ズレてると「 uv ではまだロックできないバージョン」へ上げようとする PR が来てしまう: cf. Dependency cooldown - Using uv with Dependabot
groups … マッチした依存パッケージの更新を1つの PR にまとめる。 patterns: ["*"] でそのエコシステムの更新が毎週1つの PR にまとまる。

PR の流れ¶

dependabot.yml を push すると Dependabot が依存パッケージをチェックして、 PR を作成してくれる。
※ groups でまとめてると、エコシステムごとに1つの PR にまとまって見やすいかな。

Dependabot が作成したグループ PR の一覧

PR を開くと、どの依存パッケージを何から何に上げるか、リリースノートや changelog へのリンクなどが載ってる。
GitHub Actions で、この PR をトリガーにして pytest が実行されるようにしておけば、 Dependabot の PR によるバージョンアップデートに対して自動でテストを実行できる（下の画像の Run pytest）。テストが PASS したのを確認してからマージすれば、バージョンアップデートで壊れるリスクはかなり減らせるはず。

Dependabot の PR の詳細画面

マージは Merge pull request から。 PR のコミットをどう main に取り込むかを、次の3つから選べるけど、 Squash and merge を選んでおけばいいのでは。
※ Dependabot の PR はたいてい1コミットなので、どれを選んでもほぼ同じ結果になるのでは。

PR のマージ方法（merge commit / squash / rebase）

3つのマージ方式の違い: by Claude Opus 4.8

Create a merge commit … PR のコミットを全部そのまま main に足して、さらに「ここでマージしたよ」という印のコミット（マージコミット）を1つ作る。コミットは全部残るし、どこで合流したかも履歴に残る。 GitHub のデフォルト。
Squash and merge … PR のコミットを1つにまとめてから main に足す。 PR にいくつコミットがあっても main には1コミットだけ増える。途中の細かいコミットは残らず、 PR 単位できれいにまとまる。
Rebase and merge … PR のコミットを、マージコミットなしで main の続きとして1個ずつ並べる。コミットは個別に残るけど、合流の枝分かれはできず履歴が一本の線になる。

違いを一言でいうと、 Create a merge commit は「全部残す（枝分かれも残る）」、 Squash and merge は「1コミットに潰す」、 Rebase and merge は「潰さず一本にする」。 Dependabot の PR は1コミットなのでどれでも実害はないけど、リポジトリの方針として Squash and merge に統一しておくと、人の PR も含めて履歴が一直線になって見やすい。

セキュリティアップデートの有効化¶

ここまでの dependabot.yml はバージョンアップデートの設定。セキュリティアップデートはこれとは別で、 dependabot.yml には書かずリポジトリの設定画面から有効にする。有効にすると、依存パッケージに既知の脆弱性が見つかって修正版が出てるとき、 Dependabot が自動でそのバージョンへ上げる PR を作ってくれる: cf. About Dependabot security updates

リポジトリの Settings → Advanced Security の画面から各機能を有効化できる。

GitHub の Advanced Security 設定画面

Dependency graph … 依存グラフ。脆弱性の検出はこれが前提。
Dependabot alerts … 脆弱性が見つかったらアラートを出す。
Dependabot security updates … そのアラートを解消する PR を自動で作る。

Dependabot security updates は Dependency graph と Dependabot alerts が前提なので、まとめて Enable しておく。