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 security updatesについて」を参照してください。
Dependabot によって pull request が発生する場合、その pull request は、"セキュリティ" 更新プログラムか "バージョン" アップデートを対象としたものである可能性があります。
- Dependabot security updates は、既知の脆弱性を持つ依存関係を更新するのに役立つ、自動化された pull request です。
- Dependabot version updates は、依存関係に脆弱税がなくても、依存関係を最新の状態に維持する、自動化された pull request です。 バージョンアップデートの状態をチェックするには、リポジトリのInsights（インサイト）タブ、続いてDependency Graph（依存関係グラフ）、そしてDependabotにアクセスしてください。
GitHub Actions は、GitHub Enterprise Cloud で Dependabot version updatesと Dependabot security updatesを実行するために必要です必要ありません。しかし、Dependabot によって開かれた pul request では、アクションを実行するワークフローをトリガーできます。 詳しくは、「GitHub Actions による Dependabot の自動化」を参照してください。
Dependabot とすべての関連する機能は、使用許諾契約でカバーされています。 詳細については、「GitHub Enterprise Customer Terms」を参照してください。
Dependabot のプルリクエストの頻度
設定ファイルで、新しいバージョンの各エコシステムをチェックする頻度を、毎日、毎週、毎月の中から指定します。
最初にバージョンアップデートを有効にすると、古くなった依存関係が大量にあり、中には最新バージョンまでにいくつものバージョンが存在しているものもあるかもしれません。 Dependabotは、有効化されるとすぐに古くなった依存関係をチェックします。 設定が更新するマニフェストファイルの数に応じて、設定ファイルの追加後数分のうちに、バージョンアップデートの新しいPull Requestが発行されるかもしれません。 Dependabotは、設定ファイルに対するその後の変更に対しても更新を実行します。
Dependabotは、アップデートの失敗後にマニフェストファイルを変更した際にもPull Requestを作成することがあります。 これは、アップデート失敗の原因となった依存関係の削除などのマニフェストへの変更によって、新たにトリガーされたアップデートが成功するかもしれないためです。
Pull Requestを管理可能でレビューしやすく保つために、Dependabotは依存関係を最新バージョンにし始めるためのPull Requestを最大で5つまで発行します。 次にスケジュールされているアップデートの前にこれらの最初のPull Requestの一部をマージした場合、残りのPull Requestは上限まで次のアップデート時にオープンとなります。 オープン pull request の最大数は、open-pull-requests-limit 構成オプションを設定することで変更できます。
セキュリティアップデートを有効にした場合、セキュリティアップデートの追加に対するプルリクエストが表示されることがあります。 これらは、デフォルト ブランチへの依存関係に対する Dependabot アラートによってトリガーされます。 Dependabot はプルリクエストを自動的に生成し、脆弱性のある依存関係を更新します。
サポートされているリポジトリとエコシステム
サポートされているパッケージマネージャーのいずれかの依存関係マニフェストまたはロックファイルを含むリポジトリのバージョン更新を設定できます。 一部のパッケージマネージャーでは、依存関係のベンダを設定することもできます。 詳細については、「dependabot.yml ファイルの構成オプション」を参照してください。
セキュリティあるいはバージョンアップデートを実行する際に、エコシステムによってはアップデートが成功したことを検証するためにすべての依存関係をソースから解決できなければならないことがあります。 マニフェストあるいはロックファイルにプライベートの依存関係が含まれているなら、Dependabotはそれらの依存関係がホストされている場所にアクセスできなければなりません。 Organizationのオーナーは、同じOrganization内のプロジェクトに対する依存関係を含むプライベートリポジトリへのアクセス権をDependabotに付与できます。 詳細については、「Managing security and analysis settings for your organization (組織のセキュリティと分析の設定を管理する)」を参照してください。 リポジトリの dependabot.yml 構成ファイルで、プライベート レジストリへのアクセスを構成できます。 詳細については、「dependabot.yml ファイルの構成オプション」を参照してください。
Dependabot は、すべてのパッケージマネージャーに対してプライベートな GitHub 依存関係をサポートしません。 詳細は、以下の表をご覧ください。
以下の表は、各パッケージマネージャについて以下の項目を示しています。
- dependabot.ymlファイル中で使う YAML 値
- パッケージマネージャのサポートされているバージョン
- プライベートのGitHubリポジトリあるいはレジストリ内の依存関係がサポートされているか
- ベンダーの依存関係がサポートされているか
| パッケージ マネージャー | YAML値 | サポートされているバージョン | プライベートリポジトリ | プライベート レジストリ | ベンダー |
|---|---|---|---|---|---|
| Bundler | bundler | v1, v2 | ✓ | ✓ | |
| Cargo | cargo | v1 | ✓ | ✓ | |
| Composer | composer | v1, v2 | ✓ | ✓ | |
| Docker [1] | docker | v1 | ✓ | ✓ | |
| Hex | mix | v1 | ✓ | ||
| elm-package | elm | v0.19 | ✓ | ✓ | |
| Gitサブモジュール | gitsubmodule | N/A (バージョンなし) | ✓ | ✓ | |
| GitHub Actions [2] | github-actions | N/A (バージョンなし) | ✓ | ✓ | |
| Go モジュール | gomod | v1 | ✓ | ✓ | ✓ |
| Gradle [3] | gradle | N/A (バージョンなし) | ✓ | ✓ | |
| Maven [4] | maven | N/A (バージョンなし) | ✓ | ✓ | |
| npm | npm | v6、v7、v8 | ✓ | ✓ | |
| NuGet | nuget | <= 4.8[5] | ✓ | ✓ | |
| pip[6] | pip | v21.1.2 | ✓ | ||
| pipenv | pip | <= 2021-05-29 | ✓ | ||
| pip-compile[6] | pip | 6.1.0 | ✓ | ||
| poetry | pip | v1 | ✓ | ||
| pub [7] | pub | v2 | |||
| Terraform | terraform | >= 0.13、<= 1.3.x | ✓ | ✓ | |
| yarn | npm | v1、v2、v3 | ✓ | ✓ | ✓[8] |
ヒント: pipenv や poetry などのパッケージ マネージャでは、pip の YAML 値を使う必要があります。 たとえば Python の依存関係を管理するのに poetry を使っており、Dependabot に新しいバージョンのために依存関係のマニフェスト ファイルをモニターさせたい場合は、dependabot.yml ファイル中で package-ecosystem: "pip" を使ってください。
[1] Dependabot では、Kubernetes マニフェストの Docker イメージ タグを更新できます。 Docker イメージ タグを参照する Kubernetes マニフェストを含むディレクトリごとに、dependabot.yml ファイルの Docker package-ecosystem 要素にエントリを追加します。 Kubernetes マニフェストは、Kubernetes Deployment YAML ファイルまたは Helm チャートにすることができます。 docker の dependabot.yml ファイルの構成について詳しくは、「dependabot.yml ファイルの構成オプション」の「package-ecosystem」を参照してください。
Dependabot では、パブリックとプライベートの両方の Docker レジストリがサポートされています。 サポートされているレジストリの一覧については、「dependabot.yml ファイルの構成オプション」の「docker-registry」を参照してください。
[2] Dependabot では、actions/checkout@v3 など、GitHub リポジトリ構文を利用した GitHub Actions の更新のみがサポートされます。 Docker Hub と GitHub Packages Container registry URL は現在、サポートされていません。
[3] Dependabot では Gradle は実行されませんが、次のファイルの更新がサポートされます: build.gradle、build.gradle.kts (Kotlin プロジェクトの場合)、および apply 宣言を使用して組み込まれた、ファイル名に dependencies を含むファイル。 apply では、apply to、再帰、または高度な構文 (たとえば、ファイル名がプロパティで定義された、Kotlin の mapOf 付き apply) はサポートされていないことに注意してください。
[4] Dependabot では Maven は実行されませんが、pom.xml ファイルの更新はサポートされます。
[5] Dependabot では NuGet CLI は実行されませんが、バージョン 4.8 までのほとんどの機能がサポートされます。
[6] requirements.txt ファイルの更新のサポートに加え、Dependabot では、PEP 621 標準に従っている場合、pyproject.toml ファイルの更新がサポートされます。
[7] Dependabot は、以前のバージョンが使用可能な場合でも、更新を試みるバージョンが無視されているときは pub の更新を実行しません。
[8] Dependabot では v2 以降のベンダー依存関係がサポートされています。
リポジトリですでに依存関係管理にインテグレーションを使用している場合は、Dependabot を有効にする前にそれを無効にする必要があります。 詳細については、「統合について」を参照してください。
Dependabot updates の自動非アクティブ化について
リポジトリのメンテナが Dependabot pull request の操作を停止すると、Dependabot はその更新を一時的に停止し、そのことが通知されます。 この自動オプトアウト動作により、Dependabot はバージョンとセキュリティ更新プログラムの pull request を作成せず、Dependabot は非アクティブなリポジトリのプル要求をリベースしないため、ノイズが軽減されます。
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 バージョン更新の通知について
GitHub で通知をフィルター処理して、Dependabot によって作成された pull request の通知を表示できます。 詳細については、「受信トレイからの通知の管理」を参照してください。