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 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に付与できます。 詳しくは、「Organization のセキュリティおよび分析設定を管理する」を参照してください。 リポジトリの dependabot.yml 構成ファイルで、プライベート レジストリへのアクセスを構成できます。 詳しくは、「dependabot.yml ファイルの構成オプション」を参照してください。
Dependabot は、すべてのパッケージマネージャーに対してプライベートな GitHub 依存関係をサポートしません。 詳細は、以下の表をご覧ください。
以下の表は、各パッケージマネージャについて以下の項目を示しています。
- dependabot.ymlファイル中で使う YAML 値
- パッケージマネージャのサポートされているバージョン
- プライベートのGitHubリポジトリあるいはレジストリ内の依存関係がサポートされているか
- ベンダーの依存関係がサポートされているか
| パッケージ マネージャー | YAML値 | サポートされているバージョン | プライベートリポジトリ | プライベート レジストリ | ベンダー |
|---|---|---|---|---|---|
| Bundler | bundler | v1, v2 | |||
| Cargo | cargo | v1 | (git のみ) | ||
| 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 | |||
| NuGet | nuget | <= 4.8 | |||
| pip | pip | v21.1.2 | |||
| pipenv | pip | <= 2021-05-29 | |||
| pip-compile | pip | 6.1.0 | |||
| poetry | pip | v1 | |||
| pub | pub | v2 | |||
| Terraform | terraform | >= 0.13、<= 1.3.x | 適用できません | ||
| yarn | npm | v1、v2、v3 |
ヒント: pipenv や poetry などのパッケージ マネージャでは、pip の YAML 値を使う必要があります。 たとえば Python の依存関係を管理するのに poetry を使っており、Dependabot に新しいバージョンのために依存関係のマニフェスト ファイルをモニターさせたい場合は、dependabot.yml ファイル中で package-ecosystem: "pip" を使ってください。
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 イメージ タグを参照する Kubernetes マニフェストを含むディレクトリごとに、dependabot.yml ファイルの Docker package-ecosystem 要素にエントリを追加します。 Kubernetes マニフェストは、Kubernetes Deployment YAML ファイルまたは Helm チャートにすることができます。 docker の dependabot.yml ファイルの構成については、「dependabot.yml ファイルの構成オプション」の「package-ecosystem」を参照してください。
Dependabot では、パブリックとプライベートの両方の Docker レジストリがサポートされています。 サポートされているレジストリの一覧については、「dependabot.yml ファイルの構成オプション」の「docker-registry」を参照してください。
GitHub Actions
Dependabot は、actions/checkout@v3 などの GitHub リポジトリ構文を使って、GitHub Actions に対する更新のみをサポートします。 Docker Hub と GitHub Packages Container registry URL は現在、サポートされていません。
Gradle
Dependabot では Gradle は実行されませんが、次のファイルの更新はサポートされます。
build.gradle、build.gradle.kts(Kotlin プロジェクト)gradle/libs.versions.toml(標準 Gradle バージョン カタログを使用するプロジェクトの場合)apply宣言を介して追加され、ファイル名にdependenciesが含まれるファイル。applyでは、apply to、再帰、または高度な構文 (たとえば、ファイル名がプロパティで定義された、Kotlin のmapOf付きapply) はサポートされていないことに注意してください。
Maven
Dependabot では Maven は実行されませんが、pom.xml ファイルの更新はサポートされます。
NuGet CLI
Dependabot では NuGet CLI は実行されませんが、バージョン 4.8 までのほとんどの機能がサポートされます。
pip と pip-compile
requirements.txt ファイルの更新のサポートに加え、Dependabot は、PEP 621 標準に従っている pyproject.toml ファイルの更新をサポートします。
pub
Dependabot は、以前のバージョンが使用可能な場合でも、更新を試みるバージョンが無視されているときは pub の更新を実行しません。
yarn
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 は、バージョンとセキュリティの更新に関する pull request のリベースも 30 日後に停止するので、非アクティブな Dependabot の pull request に対する通知が減ります。
Dependabot バージョン更新の通知について
GitHub で通知をフィルター処理して、Dependabot によって作成された pull request の通知を表示できます。 詳しくは、「インボックスからの通知を管理する」を参照してください。