GitHub Dependabot のバージョンアップデートについて

Dependabot version updates について

Dependabot は、依存関係を維持する手間を省きます。 これを使用して、リポジトリが依存するパッケージおよびアプリケーションの最新リリースに自動的に対応できるようにすることができます。

dependabot.yml 構成ファイルをリポジトリにチェックインして、Dependabot version updates を有効にします。 設定ファイルは、リポジトリに保存されているマニフェストまたは他のパッケージ定義ファイルの場所を指定します。 Dependabot ではこの情報を使用して、期限切れのパッケージとアプリケーションが検査されます。 Dependabot では、依存関係のセマンティック バージョニング (semver) を調べて、依存関係の新しいバージョンの有無が判断され、そのバージョンへ更新すべきかどうかが決定されます。 特定のパッケージマネージャーでは、Dependabot version updates もベンダをサポートしています。 ベンダ (またはキャッシュ) された依存関係は、マニフェストで参照されるのではなく、リポジトリ内の特定のディレクトリにチェックインされる依存関係です。 パッケージサーバーが利用できない場合でも、ビルド時にベンダ依存関係を利用できます。 Dependabot version updates は、ベンダの依存関係をチェックして新しいバージョンを確認し、必要に応じて更新するように設定できます。

Dependabot で以前の依存関係が特定されると、マニフェストを依存関係の最新バージョンに更新する pull request が発行されます。 ベンダーの依存関係の場合、Dependabot はプルリクエストを生成して、古い依存関係を新しいバージョンに直接置き換えます。 テストに合格したことを確認し、プルリクエストの概要に含まれている変更履歴とリリースノートを確認して、マージします。 詳しくは、「Dependabot のバージョン アップデートの設定」を参照してください。

セキュリティ更新プログラム を有効にすると、Dependabot でも pull request が発行され、脆弱性のある依存関係を更新します。 詳しくは、「Dependabot のセキュリティ アップデート」を参照してください。

Dependabot によって pull request が発生する場合、その pull request は、"セキュリティ" 更新プログラムか "バージョン" アップデートを対象としたものである可能性があります。

• Dependabot security updates は、既知の脆弱性を持つ依存関係を更新するのに役立つ、自動化された pull request です。
• Dependabot version updates は、依存関係に脆弱税がなくても、依存関係を最新の状態に維持する、自動化された pull request です。 バージョンアップデートの状態をチェックするには、リポジトリのInsights（インサイト）タブ、続いてDependency Graph（依存関係グラフ）、そしてDependabotにアクセスしてください。

GitHub Actions は、GitHub で Dependabot version updatesと Dependabot security updatesを実行するために必要です必要ありません。しかし、Dependabot によって開かれた pul request では、アクションを実行するワークフローをトリガーできます。 詳細については、「GitHub ActionsでのDependabotの自動化」を参照してください。

Dependabot とすべての関連する機能は、GitHub の利用規約でカバーされています。

Dependabot のプルリクエストの頻度

設定ファイルで、新しいバージョンの各エコシステムをチェックする頻度を、毎日、毎週、毎月の中から指定します。

最初にバージョンアップデートを有効にすると、古くなった依存関係が大量にあり、中には最新バージョンまでにいくつものバージョンが存在しているものもあるかもしれません。 Dependabotは、有効化されるとすぐに古くなった依存関係をチェックします。 設定が更新するマニフェストファイルの数に応じて、設定ファイルの追加後数分のうちに、バージョンアップデートの新しいPull Requestが発行されるかもしれません。 Dependabotは、設定ファイルに対するその後の変更に対しても更新を実行します。

Dependabotは、アップデートの失敗後にマニフェストファイルを変更した際にもPull Requestを作成することがあります。 これは、アップデート失敗の原因となった依存関係の削除などのマニフェストへの変更によって、新たにトリガーされたアップデートが成功するかもしれないためです。

Pull Requestを管理可能でレビューしやすく保つために、Dependabotは依存関係を最新バージョンにし始めるためのPull Requestを最大で5つまで発行します。 次にスケジュールされているアップデートの前にこれらの最初のPull Requestの一部をマージした場合、残りのPull Requestは上限まで次のアップデート時にオープンとなります。 オープン pull request の最大数は、open-pull-requests-limit 構成オプションを設定することで変更できます。

表示される pull request の数をさらに減らすには、groups 構成オプションを使って、(パッケージ エコシステムごとに) 依存関係のセットをまとめてグループ化できます。 その後、Dependabot により、グループ内のできるだけ多くの依存関係を一度に最新バージョンに更新する、1 つの pull request が生成されます。詳細については「依存関係の更新をカスタマイズする」を参照してください。

セキュリティアップデートを有効にした場合、セキュリティアップデートの追加に対するプルリクエストが表示されることがあります。 これらは、デフォルト ブランチへの依存関係に対する Dependabot アラートによってトリガーされます。 Dependabot はプルリクエストを自動的に生成し、脆弱性のある依存関係を更新します。

構成ミスやバージョンに互換性がないために Dependabot の実行に失敗したと表示されることがあります。 実行に 30 回失敗すると、依存関係グラフからの更新を手動でトリガーするか、マニフェスト ファイルを更新するまで、Dependabot version updates はその後のスケジュールされた実行をスキップします。 Dependabot security updates は、通常どおり、引き続き実行されます。

サポートされているリポジトリとエコシステム

サポートされているパッケージマネージャーのいずれかの依存関係マニフェストまたはロックファイルを含むリポジトリのバージョン更新を設定できます。 一部のパッケージマネージャーでは、依存関係のベンダを設定することもできます。 詳しくは、「dependabot.yml ファイルの構成オプション」を参照してください。

以下の表は、各パッケージマネージャについて以下の項目を示しています。

• dependabot.yml ファイルで使用する YAML VALUE
• パッケージマネージャのサポートされているバージョン
• プライベートのGitHubリポジトリあるいはレジストリ内の依存関係がサポートされているか
• ベンダーの依存関係がサポートされているか

パッケージ マネージャー	YAML値	サポートされているバージョン	プライベートリポジトリ	プライベート レジストリ	ベンダー
Bundler	bundler	v1, v2
Cargo	cargo	v1		(git only)
Composer	composer	v1, v2
Docker	docker	v1			適用できません
Hex	mix	v1
elm-package	elm	v0.19
Gitサブモジュール	gitsubmodule	適用なし			適用できません
GitHub Actions	github-actions	適用なし			適用できません
Go モジュール	gomod	v1
Gradle	gradle	適用なし
Maven	maven	適用なし
npm	npm	v6, v7, v8, v9
NuGet	nuget	<= 4.8
pip	pip	v21.1.2
pipenv	pip	<= 2021-05-29
pip-compile	pip	6.1.0
pnpm	npm	v7, v8
poetry	pip	v1
pub	pub	v2
Swift	swift	v5		(git only)
Terraform	terraform	>= 0.13, <= 1.5.x			適用できません
yarn	npm	v1、v2、v3

Cargo

プライベート レジストリのサポートは Git レジストリに適用され、cargo レジストリは含まれません。

Docker

Dependabot は、バージョンの更新に関する pull request に Docker イメージからのメタデータを追加できます。 メタデータには、リリース ノート、変更ログ、コミット履歴が含まれます。 リポジトリ管理者は、このメタデータを使って、依存関係の更新の安定性リスクをすばやく評価できます。

Dependabot で Docker のメタデータをフェッチするには、Docker イメージのメンテナーが Dockerfile に org.opencontainers.image.source ラベルを追加し、ソース リポジトリの URL を含める必要があります。 さらに、メンテナーは、発行された Docker イメージと同じタグでリポジトリにタグを付ける必要があります。 例については、dependabot-fixtures/docker-with-source リポジトリをご覧ください。 Docker のラベルについて詳しくは、Docker のドキュメントの「拡張イメージ ラベル」と「BUILDX_GIT_LABELS」をご覧ください。

Dependabot は、Kubernetes マニフェストの Docker イメージ タグを更新できます。 Docker Image タグを参照する Kubernetes マニフェストを含むディレクトリごとに、dependabot.yml ファイルの Docker package-ecosystem 要素に入力を追加します。 Kubernetes マニフェストは、Kubernetes Deployment YAML ファイルまたは Helm チャートにすることができます。 dependabot.yml ファイルをdockerに構成する情報提供については、「dependabot.yml ファイルの構成オプション」の「package-ecosystem」を参照してください。

Dependabot では、パブリックとプライベートの両方の Docker レジストリがサポートされています。 サポートされているレジストリの一覧については、「dependabot.yml ファイルの構成オプション」の「docker-registry」を参照してください。

GitHub Actions

Dependabot は、actions/checkout@v4 などの GitHub リポジトリ構文を使って、GitHub Actions に対する更新のみをサポートします。 Docker Hub と GitHub Packages Container registry URL は現在、サポートされていません。

Dependabot では、GitHub Actions のパブリック リポジトリとプライベート リポジトリの両方がサポートされます。 プライベート レジストリの構成オプションについては、「dependabot.yml ファイルの構成オプション」の「git」を参照してください。

Gradle

Dependabot では Gradle は実行されませんが、次のファイルの更新はサポートされます。

• build.gradle、build.gradle.kts (Kotlin プロジェクト)
• gradle/libs.versions.toml (標準 Gradle バージョン カタログを使用するプロジェクトの場合)
• apply 宣言を介して追加され、ファイル名に dependencies が含まれるファイル。 apply では、apply to、再帰、または高度な構文 (たとえば、ファイル名がプロパティで定義された、Kotlin の mapOf 付き apply) はサポートされていないことに注意してください。

Dependabot security updates の場合、Gradle のサポートは、Dependency Submission API を使用した依存関係グラフ データの手動アップロードに限定されます。 Dependency Submission API の詳細については、「Dependency Submission API を使用する」を参照してください。

Maven

Dependabot では Maven は実行されませんが、pom.xml ファイルの更新はサポートされます。

NuGet CLI

Dependabot では NuGet CLI は実行されませんが、バージョン 4.8 までのほとんどの機能がサポートされます。

pip と pip-compile

requirements.txt ファイルの更新のサポートに加え、Dependabot は、PEP 621 標準に従っている pyproject.toml ファイルの更新をサポートします。

pnpm

pnpm は、Dependabot version updates と Dependabot security updates でサポートされています。

pub

Dependabot は、以前のバージョンが使用可能な場合でも、更新を試みるバージョンが無視されているときは pub の更新を実行しません。

Swift

プライベート レジストリのサポートは、git レジストリにのみ適用されます。 Swift レジストリはサポートされていません。 非宣言型マニフェストはサポートされていません。 非宣言型マニフェストの詳細については、Swift Evolution ドキュメントの「非宣言型マニフェストの編集」を参照してください。

yarn

Dependabot では、v2 以降のベンダー依存関係がサポートされています。

リポジトリですでに依存関係管理にインテグレーションを使用している場合は、Dependabot を有効にする前にそれを無効にする必要があります。 詳しくは、「統合の使用について」をご覧ください。

Dependabot updates の自動非アクティブ化について

リポジトリのメンテナが Dependabot pull request の操作を停止すると、Dependabot はその更新を一時的に停止し、そのことが通知されます。 この自動オプトアウト動作により、Dependabot はバージョンとセキュリティの更新に関する pull request を作成せず、非アクティブなリポジトリに対する Dependabot の pull request をリベースしないため、ノイズが減ります。

Dependabot 更新の自動非アクティブ化は、Dependabot で pull request が開かれたが、pull request はそのまま残っているリポジトリにのみ適用されます。 Dependabot で pull request が開かれていない場合、Dependabot は一時停止されません。

アクティブなリポジトリとは、(Dependabot ではなく) ユーザーが過去 90 日間に以下の "いずれか" のアクションを実行したリポジトリです。__

• リポジトリの Dependabot pull request をマージするか閉じる。
• リポジトリの dependabot.yml ファイルに変更を加える。
• セキュリティ更新プログラムまたはバージョン更新プログラムを手動でトリガーする。
• リポジトリの Dependabot security updates を有効にする。
• pull request で @dependabot コマンドを使う。

非アクティブなリポジトリとは、少なくとも 1 つの Dependabot pull request が 90 日を超えて開かれ、全期間に渡って有効になっており、上記のどのアクションもユーザーによって実行されていないリポジトリです。

Dependabot が一時停止すると、GitHub は開いているすべての Dependabot pull request の本文に通知を追加し、これらの pull request に dependabot-paused ラベルを割り当てます。 また、リポジトリの [設定] タブの UI ( [コードのセキュリティと分析] 、 [Dependabot] ) と、Dependabot alerts の一覧にも (Dependabot security updates が影響を受ける場合) バナー通知が表示されます。

メンテナが Dependabot pull request と再びやり取りするとすぐに、Dependabot によりそれ自体の一時停止が解除されます。

• Dependabot alerts のセキュリティ更新プログラムが自動的に再開されます。
• バージョンの更新は、dependabot.yml ファイルで指定されたスケジュールで自動的に再開されます。

Dependabot は、バージョンとセキュリティの更新に関する pull request のリベースも 30 日後に停止するので、非アクティブな Dependabot の pull request に対する通知が減ります。

Dependabot バージョン更新の通知について

GitHub で通知をフィルター処理して、Dependabot によって作成された pull request の通知を表示できます。 詳しくは、「インボックスからの通知を管理する」を参照してください。