Dependabot エラーについて
Dependabot は、依存関係を更新するPull Requestを生成します。 リポジトリの設定によっては、Dependabot がバージョン更新やセキュリティアップデートのPull Requestを発行する場合があります。 これらのPull Requestは、他のPull Requestと同じ方法で管理しますが、追加のコマンドもいくつか用意されています。 Dependabot の依存関係更新プログラムの有効化については、「Configuring Dependabot security updates (Dependabot セキュリティ アップデートの構成)」と「Dependabot のバージョン アップデートの設定」を参照してください。
何らかが Dependabot によるプルリクエストの発行を妨げる場合、エラーとして報告されます。
注: Dependabot では、非アクティブなリポジトリの pull request は作成されません。 非アクティブ状態の条件の詳細については、セキュリティに関しては「Dependabot のセキュリティ アップデート」を、バージョンの更新に関しては「GitHub Dependabot のバージョンアップデートについて」をそれぞれ参照してください。
GitHub Actions ランナーの Dependabot を実行するときのトラブルシューティングの詳細については、「GitHub Actions ランナーの Dependabot について」を参照してください。
Dependabot security updates でエラーを調査する
Dependabot が Dependabot アラートを修正するためのプルリクエストの作成をブロックされると、アラートにエラーメッセージを投稿します。 Dependabot alerts ビューには、未解決のアラートのリストが表示されます。 アラート ビューにアクセスするには、リポジトリの Security タブで [Dependabot alerts] をクリックします。 脆弱性のある依存関係を修正するプルリクエストが生成された場合、アラートにはそのプルリクエストへのリンクが含まれます。
アラートに pull request リンクがない理由は、いくつかあります。
- Dependabot security updates がリポジトリに対して有効になっていない。
- アラートが、ロックファイルで明示的に定義されていない間接的または推移的な依存関係に対するものである。
- エラーにより Dependabot のプルリクエストの作成がブロックされました。
エラーによって Dependabot によるプルリクエストの作成がブロックされた場合は、アラートをクリックしてエラーの詳細を表示できます。
Dependabot version updates
でエラーを調査する
Dependabot がエコシステム内の依存関係を更新するためのプル要求の作成をブロックされている場合、 はジョブ ログの一覧を表示して、エラー に投稿されます。
ジョブ ログの一覧には、リポジトリの依存関係グラフからアクセスできます。 依存関係グラフから Dependabot タブをクリックし、影響を受けるマニフェスト ファイルの右側にある [最近の更新ジョブ] をクリックします。
特定のジョブの完全なログ ファイルを表示するには、目的のログ エントリの右側にある [ログの表示] をクリックします。
詳しくは、「Dependabot ジョブ ログの表示」を参照してください。
Dependabot エラーを理解する
セキュリティアップデートのプルリクエストは、脆弱性のある依存関係を、脆弱性の修正を含む最小バージョンにアップグレードします。 対照的に、バージョン更新のプルリクエストは、パッケージマニフェストおよび Dependabot 設定ファイルで許可されている最新バージョンに依存関係をアップグレードするように動作します。 したがって、一部のエラーは 1 つの種類の更新に固有になります。
Dependabot が DEPENDENCY を脆弱でないバージョンに更新できない
セキュリティ アップデートのみ。 Dependabot は、このリポジトリの依存関係グラフの他の依存関係を壊さずに、脆弱性のある依存関係を安全なバージョンに更新するための pull request を作成することはできません。
依存関係を含むすべてのアプリケーションには、依存関係グラフ、つまり、アプリケーションが直接または間接的に依存するすべてのパッケージバージョンの有向非巡回グラフがあります。 依存関係が更新されるたびに、このグラフを解決する必要があります。解決しない場合、アプリケーションがビルドされません。 npm や RubyGems のように、エコシステムに深く複雑な依存関係グラフがある場合、エコシステム全体をアップグレードせずに単一の依存関係をアップグレードすることは不可能な場合があります。
この問題を回避する最善策としては、たとえばバージョン更新を有効化するなどして、最新のリリースバージョンで最新の状態に保つことです。 これにより、依存関係グラフを壊さない単純なアップグレードで 1 つの依存関係の脆弱性を解決できる可能性が高くなります。 詳しくは、「Dependabot のバージョン アップデートの設定」を参照してください。
Dependabot がアラートなしで依存関係を更新しようとする
セキュリティ アップデートのみ。 Dependabot は、すべてのエコシステムに対して脆弱な、明示的に定義された推移的な依存関係を更新します。 npm の場合、Dependabot は、それが推移的な依存関係を修正する唯一の方法である場合、親依存関係も更新する pull request を発生させます。
たとえば、1.0.1 に解決され、B バージョン ~1.0.0 への推移的な依存関係がある、A バージョン ~2.0.0 への依存関係があるプロジェクトなどです。
my project
|
--> A (2.0.0) [~2.0.0]
|
--> B (1.0.1) [~1.0.0]
B バージョン <2.0.0 に対してセキュリティの脆弱性がリリースされ、パッチが 2.0.0 で利用可能である場合、Dependabot は B への更新を試みますが、脆弱性の低いバージョンのみが許可される A による制限があるため、更新できません。 この脆弱性を解決するために、Dependabot は B の固定バージョンを使用できるようにする、依存関係 A の更新プログラムを検索します。
Dependabot は、ロックされた親と子両方の推移的な依存関係をアップグレードする pull request を自動的に生成します。
Dependabot は、既定のブランチに既に適用されている更新プログラムのオープン pull request をクローズすることはできません。
Dependabot は、依存関係の更新が既定のブランチにコミットされたことを検出すると、その更新に対する pull request をクローズします。 ただし、まれな状況では、pull request が開いたままとなる可能性があります。 依存関係の更新を手動でコミットし、その同じ更新プログラムの pull request がまだ開いている場合は、pull request のコメントで次のいずれかのコマンドを使用できます。
@dependabot recreate、または@dependabot rebase。
どちらのコメントでも、Dependabot を起動し、依存関係がアップグレードできなくなったかどうか、脆弱性があるかどうかをチェックします。 Dependabot が pull request が不要になったと検出した場合、そのケースに関する pull request を閉じます。
Dependabot のコメント コマンドについて詳しくは、「依存関係の更新に関するPull Requestを管理する」をご覧ください。
最新バージョンのオープンプルリクエストがすでに存在するため、Dependabot を必要なバージョンに更新できない
セキュリティ アップデートのみ。 この依存関係を更新するための pull request は既に開かれているため、Dependabot で脆弱性のある依存関係を安全なバージョンに更新するための pull request は作成されません。 このエラーは、単一の依存関係で脆弱性が検出され、依存関係を最新バージョンに更新するためのオープンプルリクエストがすでに存在する場合に表示されます。
オープンプルリクエストを確認して、変更が安全であると確信したらすぐにマージするか、そのプルリクエストをクローズして新しいセキュリティアップデートプルリクエストをトリガーする、という 2 つのオプションがあります。 詳細については、「Dependabot のプル リクエストを手動でトリガーする」を参照してください。
DEPENDENCY が脆弱ではなくなったため、セキュリティ更新プログラムは必要ありません
セキュリティ アップデートのみ。 Dependabot では、 pull request を閉じて、脆弱ではない、または脆弱ではなくなった依存関係を更新することはできません。 このエラーは、依存関係グラフ データが古いときや、依存関係の特定のバージョンが脆弱な場合に依存関係グラフと Dependabot が一致しないときに発生する可能性があります。
この問題をデバッグするには、まずリポジトリの依存関係グラフを調べ、依存関係で検出されたバージョンを確認し、識別されたバージョンがリポジトリで使用されているものと一致するかどうかをチェックすることをお勧めします。
依存関係グラフ データが古くなっていると思われる場合は、リポジトリの依存関係グラフを手動で更新するか、依存関係情報をさらに調査する必要があります。 詳しくは、「依存関係グラフのトラブルシューティング」を参照してください。
依存関係のバージョンが脆弱でなくなったかどうかを確認できる場合は、Dependabot pull request を閉じてください。
Dependabot が更新中にタイムアウトした
Dependabot は、必要な更新を評価してプルリクエストを準備するために許可された最大時間よりも長く時間を要しました。 このエラーは、通常、多くのマニフェスト ファイルを含む大規模なリポジトリでのみ発生します。たとえば、数百の package.json ファイルを含む npm や yarn monorepo プロジェクトなどです。 Composer エコシステムの更新も評価に時間がかかり、タイムアウトする可能性があります。
これは対処が難しいエラーです。 バージョン更新がタイムアウトする場合は、allow パラメーターを使用して更新する最も重要な依存関係を指定するか、または ignore パラメーターを使用して更新から一部の依存関係を除外できます。 設定を更新すると、Dependabot がバージョンの更新を確認し、利用可能な時間内にプルリクエストを生成できます。
セキュリティアップデートがタイムアウトする場合、たとえばバージョン更新を有効にするなどして依存関係を最新に保つことで、タイムアウトが発生する可能性を減らすことができます。 詳しくは、「Dependabot のバージョン アップデートの設定」を参照してください。
Dependabot で追加のプルリクエストをオープンできない
Dependabot が生成するオープンプルリクエスト数には制限があります。 上限に達すると、新しいプルリクエストはオープンされず、このエラーが報告されます。 エラーを解決する最善策として、複数のオープンプルリクエストを確認してマージします。
セキュリティアップデートとバージョン更新のプルリクエストには個別の制限があるため、オープンなバージョン更新のプルリクエストがセキュリティアップデートのプルリクエストの作成をブロックすることはできません。 セキュリティアップデートのプルリクエストの上限は 10 件です。 既定では、バージョン アップデートの上限は 5 件ですが、構成ファイルで open-pull-requests-limit パラメータを使用してこれを変更できます。 詳しくは、「dependabot.yml ファイルの構成オプション」を参照してください。
このエラーを解決する最善策として、既存のプルリクエストの一部をマージまたはクローズして、新しいプルリクエストを手動でトリガーします。 詳細については、「Dependabot のプル リクエストを手動でトリガーする」を参照してください。
Dependabot が依存関係を解決またはアクセスできない
Dependabot がリポジトリで依存関係のリファレンスを更新する必要があるかどうかを確認しようとしたが、1 つ以上のリファレンスファイルにアクセスできない場合、操作は失敗し、「Dependabot は LANGUAGE 依存関係ファイルを解決できません」というエラーメッセージが表示されます。 API エラーの種類は git_dependencies_not_reachable です。
同様に、Dependabot が依存関係が存在するプライベートパッケージレジストリにアクセスできない場合、次のエラーのいずれかが生成されます。
- "Dependabot can't reach a dependency in a private package registry" (Dependabot はプライベート パッケージ レジストリ内の依存関係に到達できません)
(API エラーの種類:private_source_not_reachable) - "Dependabot can't authenticate to a private package registry" (Dependabot はプライベート パッケージ レジストリを認証できません)
(API エラーの種類:private_source_authentication_failure) - "Dependabot timed out while waiting for a private package registry" (プライベート パッケージ レジストリの待機中に Dependabot がタイムアウトしました)
(API エラーの種類:private_source_timed_out) - "Dependabot couldn't validate the certificate for a private package registry" (Dependabot はプライベート パッケージ レジストリの証明書を検証できませんでした)
(API エラーの種類:private_source_certificate_failure)
Dependabot が依存関係のリファレンスを正常に更新できるようにするには、すべての依存関係のリファレンスがアクセス可能な場所でホストされていることを確認してください。
バージョンアップデートのみ。 セキュリティあるいはバージョンアップデートを実行する際に、エコシステムによってはアップデートが成功したことを検証するためにすべての依存関係をソースから解決できなければならないことがあります。 マニフェストあるいはロックファイルにプライベートの依存関係が含まれているなら、Dependabotはそれらの依存関係がホストされている場所にアクセスできなければなりません。 Organizationのオーナーは、同じOrganization内のプロジェクトに対する依存関係を含むプライベートリポジトリへのアクセス権をDependabotに付与できます。 詳しくは、「組織のセキュリティおよび分析設定を管理する」を参照してください。 リポジトリの dependabot.yml 構成ファイルで、プライベート レジストリへのアクセスを構成できます。 詳しくは、「dependabot.yml ファイルの構成オプション」を参照してください。 さらに、 Dependabot はすべてのパッケージマネージャーに対して、プライべートな GitHub 依存関係をサポートしません。 詳しくは、「Dependabot でサポートされているエコシステムとリポジトリ」を参照してください。
Dependabot で依存関係のセットを Dependabot version updates
の 1 つの pull request にグループ化できない
dependabot.yml ファイル内の groups 構成設定は、バージョン更新とセキュリティ アップデートに適用できます。 applies-to キーを使用して、グループ化ルールのセットを適用する場所 (バージョン更新またはセキュリティ アップデート) を指定します。
バージョン_更新と_セキュリティ アップデートの両方に、1 つのグループ化ルール セットを適用することはできません。 代わりに、同じ条件を使用してバージョン更新プログラムとセキュリティ アップデート プログラムの両方をグループ化する場合は、個別に名前を付けた 2 つのルール セットを定義する必要があります。
グループ化されたバージョンの更新プログラムを構成する場合は、パッケージ エコシステムごとにグループを構成する必要があります。 この問題をデバッグするには、ログを確認することをお勧めします。 マニフェストのログへのアクセスの詳細については、上記の「Dependabot version updatesでのエラーの調査」を参照してください。
意図せずに空のグループを作成した可能性があります。 これは例えば、仕事全体の allow キーに dependency-type をセットした場合に起こります。
allow:
dependency-type: production
# this restricts the entire job to production dependencies
groups:
development-dependencies:
dependency-type: "development"
# this group will always be empty
この例では、Dependabot は次のようになります:
- 依存関係リストを確認し、ジョブを
productionで使用する依存関係のみに制限します。 - この縮小リストのサブセットである、呼び出されたグループ
development-dependenciesを作成してみてください。 - 手順 1 ですべての
development依存関係が削除され、グループがdevelopment-dependencies空であることを確認します。 - グループに含まれていないすべての依存関係を個別に更新します。 運用環境の依存関係のグループが空であるため、Dependabot はグループを無視し、依存関係ごとに個別の pull request を作成します。
構成設定が互いに取り消されないようにし、構成ファイルで適切に更新する必要があります。
Dependabot version updates のグループの構成方法について詳しくは、「dependabot.yml ファイルの構成オプション」を参照してください。
Dependabot で依存関係のセットを Dependabot security updates の 1 つの pull request にグループ化できない
dependabot.yml ファイル内の groups 構成設定は、バージョン更新とセキュリティ アップデートに適用されます。 applies-to キーを使用して、グループ化ルールのセットを適用する場所 (バージョン更新またはセキュリティ アップデート) を指定します。 セキュリティ アップデートに適用するようにグループ化が構成済みかどうかを確認します。 applies-to キーが構成内のグループ化ルールのセットに含まれていない場合、既定では、すべてのグループ ルールがバージョン更新にのみ適用されます。
バージョン_更新と_セキュリティ アップデートの両方に、1 つのグループ化ルール セットを適用することはできません。 代わりに、同じ条件を使用してバージョン更新プログラムとセキュリティ アップデート プログラムの両方をグループ化する場合は、個別に名前を付けた 2 つのルール セットを定義する必要があります。
グループ化されたセキュリティ アップデートの場合、Dependabot は次のガイドラインを使用してグループ化された pull request を作成します。
- Dependabot は、
directoriesキーを使用する構成に対してグループ化ルールが指定されている場合に、異なるディレクトリにある同じパッケージ エコシステムからの依存関係をグループ化します。 - Dependabot では、
dependabot.ymlファイルからグループ化されたセキュリティ アップデートの pull request に関連するその他のカスタマイズ オプションが適用されます。dependabot.ymlファイルで構成されたグループ ルールは、Organization またはリポジトリ レベルでグループ化されたセキュリティ アップデートを有効または無効にするためのユーザー インターフェイス設定をオーバーライドします。 - Dependabot では、異なるパッケージ エコシステムからの依存関係はグループ化されません。
- Dependabot では、セセキュリティ アップデートはバージョン更新とグループ化されません。
詳細については、「依存関係の更新をカスタマイズする」および「Dependabot のセキュリティ アップデート」を参照してください。
Dependabot でグループ化された pull request の依存関係の 1 つを更新できない
失敗したバージョン更新と失敗したセキュリティ アップデートには、さまざまなトラブルシューティング手法を使用できます。
グループ化されたバージョンの更新でのエラーの処理
バージョンアップデートのみ。 Dependabot では、ログと、ログの最後にあるジョブの概要で、失敗した更新が表示されます。 pull request で @dependabot recreate コメントを使って、グループをもう一度作成する必要があります。 詳しくは、「依存関係の更新に関するPull Requestを管理する」を参照してください。
それでも依存関係が更新されない場合は、exclude-patterns 構成を使って、その依存関係がグループから除外されるようにする必要があります。 その後、Dependabot によって個別の pull request が生成され、依存関係が更新されます。
それでも依存関係が更新されない場合は、その依存関係自体か、その特定のエコシステムの Dependabot に問題がある可能性があります。
依存関係の更新を無視する場合は、以下のいずれかの操作を行う必要があります。
ignoreファイル内の依存関係にdependabot.ymlルールを構成します。 詳しくは、「dependabot.yml ファイルの構成オプション」を参照してください。- グループ化された更新の pull request の依存関係に
@dependabot ignoreコメント コマンドを使用します。 詳しくは、「依存関係の更新に関するPull Requestを管理する」を参照してください。
グループ化されたセキュリティ アップデートでのエラーの処理
セキュリティ アップデートのみ。 セキュリティ アップデートのグループ化された pull request が失敗した場合、または統合できない場合は、pull request を手動で開いて、破壊的変更のバージョンを更新することをお勧めします。 グループ化された pull request に含まれるパッケージを手動で更新すると、Dependabot は手動で更新されたパッケージを含めないように pull request をリベースします。
依存関係の更新を無視する場合は、以下のいずれかの操作を行う必要があります。
ignoreファイル内の依存関係にdependabot.ymlルールを構成します。 詳しくは、「dependabot.yml ファイルの構成オプション」を参照してください。- グループ化された更新の pull request の依存関係に
@dependabot ignoreコメント コマンドを使用します。 詳しくは、「依存関係の更新に関するPull Requestを管理する」を参照してください。
グループ化された pull request で継続的インテグレーション (CI) が失敗する
バージョンアップデートのみ。 失敗の原因が 1 つの依存関係である場合は、exclude-patterns 構成を使って、その依存関係がグループから除外されるようにする必要があります。 その後、Dependabot によって個別の pull request が生成され、依存関係が更新されます。
依存関係の更新を無視する場合は、以下のいずれかの操作を行う必要があります。
ignoreファイル内の依存関係にdependabot.ymlルールを構成します。 詳しくは、「dependabot.yml ファイルの構成オプション」を参照してください。- グループ化された更新の pull request の依存関係に
@dependabot ignoreコメント コマンドを使用します。 詳しくは、「依存関係の更新に関するPull Requestを管理する」を参照してください。
CI が引き続き失敗する場合は、グループ構成を削除して、Dependabot が再び依存関係ごとに個別の pull request を生成するようにする必要があります。 その後、個々の pull request ごとに更新が正しく機能していることをチェックして確認する必要があります。
Dependabot のプルリクエストを手動でトリガーする
Dependabot のブロックを解除すると、プルリクエストを作成するための新規の試行を手動でトリガーできます。
- セキュリティ アップデート — 修正したエラーを示す Dependabot アラートを表示し、 [Create Dependabot security update](Dependabot のセキュリティ アップデートを作成する) をクリックします。
- バージョン アップデート — リポジトリの Insights タブで Dependency graph をクリックし、 [Dependabot] タブをクリックします。 [Last checked TIME ago](最後のチェックは <時間> 前) をクリックして、バージョン アップデートの最後のチェックの間に Dependabot によって生成されたログ ファイルを表示します。 [更新プログラムのチェック] をクリックします。