注: この機能を使用するには、サイト管理者が お使いの GitHub Enterprise Server インスタンスの Dependabot updatesを設定する必要があります。 詳しくは、「エンタープライズ向けの Dependabot の有効化」を参照してください。
Enterprise 所有者が Enterprise レベルでポリシーを設定している場合、Dependabot updatesを有効または無効にできない場合があります。 詳しくは、「エンタープライズのコード セキュリティと分析のためのポリシーの適用」をご覧ください。
dependabot.yml ファイルについて
Dependabot の構成ファイルである dependabot.yml では、YAML 構文を使います。 YAML を初めて使う場合、詳しくは「YAML を 5 分で学習する」をご覧ください。
このファイルは、既定のブランチにリポジトリの .github ディレクトリに保存する必要があります。 dependabot.yml ファイルを追加または更新すると、バージョン更新の即時チェックがトリガーされます。 詳細と例については、「Dependabot のバージョン アップデートの設定」をご覧ください。
セキュリティアップデートに影響するオプションは、次にセキュリティアラートがセキュリティアップデートのためのプルリクエストをトリガーするときにも使用されます。 詳しくは、「Configuring Dependabot security updates (Dependabot セキュリティ アップデートの構成)」を参照してください。
注: dependabot.yml ファイルを使用して Dependabot alerts を構成することはできません。
dependabot.yml ファイルには、version と updates の 2 つの必須の最上位キーがあります。 必要に応じて、最上位の registries キーを含めることができます。 このファイルは version: 2 で始まる必要があります。
実際の dependabot.yml ファイルの例については、「Dependabot 自身の構成ファイル」を参照してください。
dependabot.yml ファイルの構成オプション
最上位の updates キーは必須です。 これを使用することで、Dependabot がバージョンやプロジェクトの依存性を更新する方法を設定できます。 各エントリは、特定のパッケージマネージャーの更新設定を行います。 次のオプションを使用できます。
| オプション | 必須 | セキュリティ更新プログラム | バージョン アップデート | 説明 |
|---|---|---|---|---|
package-ecosystem | 使用するパッケージマネージャー | |||
directory | パッケージマニフェストの場所 | |||
schedule.interval | 更新を確認する頻度 | |||
allow | 許可する更新をカスタマイズする | |||
assignees | プルリクエストのアサイン担当者 | |||
commit-message | コミットメッセージの環境設定 | |||
enable-beta-ecosystems | ベータ レベルのサポートを備えたエコシステムを有効にする | |||
ignore | ignore をご覧ください。 | ignore をご覧ください。 | 特定の依存関係またはバージョンを無視する | |
insecure-external-code-execution | マニフェストファイル内でコードの実行を許可または拒否する | |||
labels | プルリクエストに設定するラベル | |||
milestone | プルリクエストに設定するマイルストーン | |||
open-pull-requests-limit | バージョン更新時のオープンなプルリクエスト数を制限する | |||
pull-request-branch-name.separator | プルリクエストブランチ名の区切り文字を変更する | |||
rebase-strategy | 自動リベースを無効にする | |||
registries | ||||
| Dependabot がアクセスできるプライベートリポジトリ | ||||
reviewers | プルリクエストのレビュー担当者 | |||
schedule.day | 更新を確認する曜日 | |||
schedule.time | 更新を確認する時刻 (hh:mm) | |||
schedule.timezone | 時刻のタイムゾーン(ゾーン識別子) | |||
target-branch | プルリクエストを作成するブランチ | |||
vendor | ベンダーまたはキャッシュされた依存関係を更新する | |||
versioning-strategy | マニフェストのバージョン要件の更新方法 | |||
| これらのオプションは、次のようなカテゴリに幅広く適合しています。 |
- すべての構成に含める必要がある基本的な設定オプション:
package-ecosystem、directory、schedule.interval。 - 更新スケジュールをカスタマイズするためのオプション:
schedule.time、schedule.timezone、schedule.day。 - 更新される依存関係を制御するオプション:
allow、ignore、vendor。 - メタデータをプルリクエストに追加するオプション:
reviewers、assignees、labels、milestone。 - プルリクエストの動作を変更するオプション:
target-branch、versioning-strategy、commit-message、rebase-strategy、pull-request-branch-name.separator。
さらに、open-pull-requests-limit オプションは、Dependabot で開くことのできるバージョン更新のプルリクエストの最大数を変更します。
注: これらの構成オプションの一部は、脆弱性のあるパッケージ マニフェストのセキュリティ更新のために送信されるプルリクエストにも影響を与える可能性があります。
脆弱性のあるパッケージマニフェストのセキュリティアップデートは、デフォルトブランチのみで発生します。 構成オプションが同じブランチに設定されていて (target-branch を使っていないかぎり該当します)、脆弱性のあるマニフェストの package-ecosystem と directory を指定している場合、セキュリティ更新のプルリクエストで関連オプションが使われます。
一般的に、セキュリティアップデートでは、メタデータの追加や動作の変更など、プルリクエストに影響する設定オプションが使用されます。 セキュリティ更新プログラムについて詳しくは、「Configuring Dependabot security updates (Dependabot セキュリティ アップデートの構成)」をご覧ください。
package-ecosystem
必須。 Dependabot で新しいバージョンを監視するパッケージ マネージャーごとに、1 つの package-ecosystem 要素を追加します。 リポジトリには、これらの各パッケージマネージャーの依存関係マニフェストまたはロックファイルも含まれている必要があります。
サポートするパッケージマネージャーに対してベンダリングを有効にする場合、ベンダリングされた依存関係が必須ディレクトリに存在する必要があります。 詳しくは、後の「vendor」をご覧ください。
バージョン更新の実行時に Dependabot がプライベート パッケージ レジストリにアクセスできるようにしたい場合は、構成ファイルに registries の設定を含めることができます。 詳しくは、「registries」をご覧ください。
注: エンタープライズ所有者は、最新バージョンの Dependabot アクションをダウンロードして、最適なエコシステム カバレッジを得ることができます。 アクションの詳細と、最新バージョンをダウンロードする方法の手順については、「公式のバンドルされたアクションの最新バージョンを使用する」を参照してください。
以下の表は、各パッケージマネージャについて以下の項目を示しています。
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 | |||
| poetry | pip | v1 | |||
| pub | pub | v2 | |||
| Terraform | terraform | >= 0.13, <= 1.8.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 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」を参照してください。
Dependabot では、セマンティック バージョニング (SemVer) の Docker イメージ タグを解析します。 Dependabot でプレリリースを含むタグが検出された場合、最新バージョンへの更新はマッチするプレリリースでのみ提案され、異なるプレリリース ラベルを使用する新しいバージョンは提案されません。 詳細については、dependabot/dependabot-core リポジトリの dependabot-docker README.md ファイルを参照してください。
GitHub Actions
Dependabot では、GitHub Actions のバージョン更新がサポートされていますが、次の点に注意してください。
- Dependabot は、
actions/checkout@v4などの GitHub リポジトリ構文を使って、GitHub Actions に対する更新のみをサポートします。 Dependabot は、ローカルで参照されているアクションまたは再利用可能なワークフロー (たとえば、./.github/actions/foo.yml) を無視します。 - Docker Hub と GitHub Packages Container registry URL は現在、サポートされていません。 たとえば、
docker://構文を使用した Docker コンテナー アクションへの参照はサポートされていません。 - Dependabot では、GitHub Actions のパブリック リポジトリとプライベート リポジトリの両方がサポートされます。 プライベート レジストリの構成オプションについては、「dependabot.yml ファイルの構成オプション」の「
git」を参照してください。
GitHub Actions での Dependabot version updates の使用について詳しくは、「GitHub のセキュリティ機能を使用して GitHub Actions の使用をセキュリティで保護する」をご覧ください。
Gradle
Gradle は Dependabot version updates でのみサポートされます。
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 ファイルの更新をサポートします。
pnpm
pnpm は、Dependabot version updates でのみサポートされています。 Dependabot security updates は現在サポートされていません。
pub
Dependabot は、以前のバージョンが使用可能な場合でも、更新を試みるバージョンが無視されているときは pub の更新を実行しません。
Terraform
Terraform のサポートには、次のものが含まれます。
- Terraform レジストリまたは一般アクセス可能な Git リポジトリでホストされているモジュール。
- Terraform プロバイダー。
- 個人用 Terraform レジストリ。
dependabot.ymlファイルで Git レジストリを指定することで、個人用 Git リポジトリのアクセスを構成できます。 詳細については、gitを参照してください。
yarn
Dependabot では、v2 以降のベンダー依存関係がサポートされています。
3 つのパッケージ マネージャーの基本的なセットアップの例
# Basic set up for three package managers
version: 2
updates:
# Maintain dependencies for GitHub Actions
- package-ecosystem: "github-actions"
# Workflow files stored in the default location of `.github/workflows`. (You don't need to specify `/.github/workflows` for `directory`. You can use `directory: "/"`.)
directory: "/"
schedule:
interval: "weekly"
# Maintain dependencies for npm
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Maintain dependencies for Composer
- package-ecosystem: "composer"
directory: "/"
schedule:
interval: "weekly"
directory
必須。 各パッケージ マネージャー (package.json や Gemfile など) のパッケージ マニフェストの場所を定義する必要があります。 GitHub Actions 以外のすべてのエコシステムで、リポジトリのルートに対する相対ディレクトリを定義します。
GitHub Actions では、ディレクトリを /.github/workflows に設定する必要はありません。 鍵を / に設定すると自動的に、Dependabot が /.github/workflows ディレクトリと、ルート ディレクトリの action.yml / action.yaml ファイルを検索するよう指示が出されます。
# Specify location of manifest files for each package manager
version: 2
updates:
- package-ecosystem: "composer"
# Files stored in repository root
directory: "/"
schedule:
interval: "weekly"
- package-ecosystem: "npm"
# Files stored in `app` directory
directory: "/app"
schedule:
interval: "weekly"
- package-ecosystem: "github-actions"
# Workflow files stored in the default location of `.github/workflows`. (You don't need to specify `/.github/workflows` for `directory`. You can use `directory: "/"`.)
directory: "/"
schedule:
interval: "weekly"
schedule.interval
必須。 各パッケージマネージャーに対して、新しいバージョンを確認する頻度を定義する必要があります。 デフォルトでは、Dependabotは設定ファイル中のすべての更新を適用する時間をランダムに割り当てます。 特定の日時を設定するには、schedule.time と schedule.timezone を使うことができます。
注: schedule.time オプションはベスト エフォート (できる限り努力する) であり、依存関係のバージョンを新しいものに更新するためのプルリクエストを Dependabot で開始するまで多少の時間がかかることがあります。
| 間隔の型 | 頻度 |
|---|---|
daily | 月曜日から金曜日までのすべての平日に実行します。 |
weekly | 毎週 1 回実行します。 デフォルトでは月曜日に設定されています。 これを変更するには、schedule.day を使います。 |
monthly | 毎月 1 回実行します。 その月の最初の日に設定されています。 |
# Set update schedule for each package manager
version: 2
updates:
- package-ecosystem: "github-actions"
# Workflow files stored in the default location of `.github/workflows`. (You don't need to specify `/.github/workflows` for `directory`. You can use `directory: "/"`.)
directory: "/"
schedule:
# Check for updates to GitHub Actions every weekday
interval: "daily"
- package-ecosystem: "composer"
directory: "/"
schedule:
# Check for updates managed by Composer once a week
interval: "weekly"
注: schedule では、Dependabot が新しい更新を試みるタイミングを定義します。 ただし、プルリクエストを受け取るタイミングはこれだけではありません。 更新は、dependabot.yml ファイルへの変更に基づいてトリガーできます。更新失敗後はマニフェストファイルまたは Dependabot security updates へ変更されます。 詳細については、「GitHub Dependabot のバージョンアップデートについて」および「Dependabot のセキュリティ アップデート」を参照してください。
allow
既定では、マニフェストで明示的に定義されているすべての依存関係が Dependabot によって最新の状態に保たれます。 さらに、Dependabot セキュリティ更新によって、ロック ファイルに定義されている脆弱な依存関係も更新されます。 保守管理する依存関係を allow と ignore を使ってカスタマイズできます。 Dependabotは許可されたすべての依存関係をチェックし、それから無視された依存関係やバージョンをフィルタリングします。 そのため、allow と ignore の両方で一致する依存関係は無視されます。
どの依存項目を更新するかをカスタマイズするには、allow オプションを使います。 これは、バージョン及びセキュリティのどちらのアップデートにも適用されます。 以下のオプションを使用できます。
-
dependency-name— 名前が一致する依存関係の更新を許可するために使います。必要に応じて、*を使って 0 個以上の文字と一致させます。- Java の依存関係の場合、
dependency-name属性の形式はgroupId:artifactIdです (例:org.kohsuke:github-api)。 - Docker イメージ タグの場合、形式はリポジトリの完全な名前です。たとえば、
<account ID>.dkr.ecr.us-west-2.amazonaws.com/base/foo/bar/ruby:3.1.0-focal-jemallocのイメージ タグの場合は、base/foo/bar/rubyを使います。
- Java の依存関係の場合、
-
dependency-type— 特定の種類の依存関係の更新を許可するために使います。依存関係の種類 パッケージマネージャーによるサポート 更新の許可 directすべて 明示的に定義されたすべての依存関係。 indirectbundler、pip、composer、cargo、gomod直接依存関係の依存関係 (サブ依存関係、または一時的依存関係とも呼ばれる)。 allすべて 明示的に定義されたすべての依存関係。 bundler、pip、composer、cargo、gomodの場合は、 直接依存関係の依存関係も。productionbundler、composer、mix、maven、npm、pip"運用依存関係グループ" の依存関係のみ。 developmentbundler、composer、mix、maven、npm、pip[開発依存関係グループ] 内の依存関係のみ。
# Use `allow` to specify which dependencies to maintain
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
allow:
# Allow updates for Lodash
- dependency-name: "lodash"
# Allow updates for React and any packages starting "react"
- dependency-name: "react*"
- package-ecosystem: "composer"
directory: "/"
schedule:
interval: "weekly"
allow:
# Allow both direct and indirect updates for all packages
- dependency-type: "all"
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
allow:
# Allow only direct updates for
# Django and any packages starting "django"
- dependency-name: "django*"
dependency-type: "direct"
# Allow only production updates for Sphinx
- dependency-name: "sphinx"
dependency-type: "production"
assignees
assignees を使って、パッケージ マネージャーに対して発行されたすべてのプルリクウェストの個々の担当者を指定します。
target-branch を使って既定以外のブランチのバージョン アップデートをチェックしないかぎり、このオプションの設定も、このパッケージ マネージャーのマニフェスト ファイルに対するセキュリティ更新プログラムの pull request に影響します。
# Specify assignees for pull requests
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Add assignees
assignees:
- "octocat"
commit-message
デフォルトでは、Dependabot はコミットメッセージの設定を検出し、同様のパターンを使用しようとします。 commit-message オプションを使って、環境設定を明示的に指定します。
サポートされているオプション
注: prefix と prefix-development オプションには、50 文字の制限があります。
-
prefixでは、すべてのコミット メッセージのプレフィックスを指定します。 コミット メッセージのプレフィックスを指定すると、定義されたプレフィックスが文字、数字、終わりかっこ、または右角かっこで終われば、GitHub によって、定義されたプレフィックスとコミット メッセージの間にコロンを自動的に追加されます。 つまり、たとえば、プレフィックスを空白で終えた場合、プレフィックスとコミット メッセージの間にコロンは追加されません。 次のコード スニペットでは、同じ構成ファイル内の両方の例を示します。 -
prefix-developmentでは、開発依存関係グループ内の依存関係を更新するすべてのコミット メッセージに個別のプレフィックスを指定します。 このオプションの値を指定すると、prefixは、プロダクション依存関係グループの依存関係の更新にのみ使われます。 これは、bundler、composer、mix、maven、npm、pipでサポートされています -
include: "scope"では、すべてのプレフィックスの後に、コミットで更新される依存関係のリストが続くことを指定します。
target-branch を使って既定以外のブランチのバージョン アップデートをチェックしないかぎり、このオプションの設定も、このパッケージ マネージャーのマニフェスト ファイルに対するセキュリティ更新プログラムの pull request に影響します。
# Customize commit messages
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
commit-message:
# Prefix all commit messages with "npm: "
prefix: "npm"
- package-ecosystem: "docker"
directory: "/"
schedule:
interval: "weekly"
commit-message:
# Prefix all commit messages with "[docker] " (no colon, but a trailing whitespace)
prefix: "[docker] "
- package-ecosystem: "composer"
directory: "/"
schedule:
interval: "weekly"
# Prefix all commit messages with "Composer" plus its scope, that is, a
# list of updated dependencies
commit-message:
prefix: "Composer"
include: "scope"
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
# Include a list of updated dependencies
# with a prefix determined by the dependency group
commit-message:
prefix: "pip prod"
prefix-development: "pip dev"
include: "scope"
上記の例と同じ構成を使用する場合、pip 開発依存関係グループの requests ライブラリを更新すると、次のコミット メッセージが生成されます。
pip dev: bump requests from 1.0.0 to 1.0.1
ignore
既定では、マニフェストで明示的に定義されているすべての依存関係が Dependabot によって最新の状態に保たれます。 さらに、Dependabot セキュリティ更新によって、ロック ファイルに定義されている脆弱な依存関係も更新されます。 保守管理する依存関係を allow と ignore を使ってカスタマイズできます。 Dependabotは許可されたすべての依存関係をチェックし、それから無視された依存関係やバージョンをフィルタリングします。 そのため、allow と ignore の両方で一致する依存関係は無視されます。
依存関係は、ignore にそれを追加するか、Dependabot によって開かれるプルリクエストで @dependabot ignore コマンドを使うことによって、無視できます。
警告:
-
Dependabot がプライベート レジストリにアクセスするのを防ぐために、
ignoreを_使用しない_ことをおすすめします。 これは一部のエコシステムで機能する可能性がありますが、パッケージ マネージャーが更新を正常に実行するためにすべての依存関係へのアクセスを必要とするかどうかを知る手段がないため、このメソッドは信頼性に欠けます。 プライベート依存関係を処理するためのサポートされた方法は、プライベート レジストリまたはプライベート リポジトリへのアクセス権を Dependabot に付与することです。 詳しくは、「Dependabot のプライベート レジストリへのアクセスの構成」を参照してください。 -
GitHub Actions と Docker の場合、
ignoreを使用して Dependabot がプライベート レジストリにアクセスするのを防ぎます。
@dependabot ignore から ignore 条件を作成する
@dependabot ignore コマンドを使って無視された依存関係は、各パッケージ マネージャーに集中的に保存されます。 dependabot.yml ファイルで依存関係の無視を始めると、これらの既存の設定が、構成での ignore の依存関係とともに考慮されます。
リポジトリで "@dependabot ignore" in:comments を検索する、または @dependabot show DEPENDENCY_NAME ignore conditions のコメント コマンドを使用することで、リポジトリに ignore のユーザー設定が保存されているかどうかを確認できます。 この方法で無視された依存関係の更新を解除したいなら、プルリクエストを再度開いてください。 これにより、pull request を終了したときに設定された ignore 条件がクリアされ、依存関係の Dependabot の更新が再開されます。 依存関係を新しいバージョンに更新するには、プルリクエストをマージします。
@dependabot ignore コマンドについて詳しくは、「依存関係の更新に関するPull Requestを管理する」をご覧ください。
無視する依存関係とバージョンを指定する
ignore オプションを使って、どの依存関係を更新するかをカスタマイズできます。 次のオプションはignore オプションでサポートされています。
| オプション | 説明 |
|---|---|
dependency-name | 名前が一致する依存関係の更新を無視するために使います。必要に応じて、* を使って 0 個以上の文字と一致させます。Java の依存関係の場合、 dependency-name 属性の形式は groupId:artifactId になります (例: org.kohsuke:github-api)。Dependabot が DefinitelyTyped の TypeScript 型定義を自動的に更新しないようにするには、 @types/* を使います。 |
versions | 特定のバージョンまたはバージョン範囲を無視するために使います。 範囲を定義する場合は、パッケージ マネージャーの標準パターンを使います。 たとえば、npm の場合は ^1.0.0 を使い、Bundler の場合は ~> 2.0 を使い、Docker の場合は Ruby バージョンの構文を使い、NuGet の場合は 7.* を使います。 |
update-types | バージョン更新での semver の major、minor、patch の更新など、更新の種類を無視するために使います (例: version-update:semver-patch でパッチの更新が無視されます)。 これを dependency-name: "*" と組み合わせると、すべての依存関係で特定の update-types を無視できます。現在サポートされているオプションは、 version-update:semver-major、version-update:semver-minor、version-update:semver-patch だけです。 |
単独で使う場合、ignore.versions キーは両方の Dependabot 更新に影響しますが、ignore.update-types キーは Dependabot version updates にのみ影響します。
ただし、versions と update-types が同じ ignore ルールで一緒に使用されている場合は、構成で target-branch を使って既定以外のブランチのバージョン更新をチェックしない限り、両方の Dependabot 更新が影響を受けます。
# Use `ignore` to specify dependencies that should not be updated
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
ignore:
- dependency-name: "express"
# For Express, ignore all Dependabot updates for version 4 and 5
versions: ["4.x", "5.x"]
# For Lodash, ignore all updates
- dependency-name: "lodash"
# For AWS SDK, ignore all patch updates for version updates only
- dependency-name: "aws-sdk"
update-types: ["version-update:semver-patch"]
- package-ecosystem: 'github-actions'
directory: '/'
schedule:
interval: 'weekly'
ignore:
- dependency-name: 'actions/checkout'
# For GitHub Actions, ignore all updates greater than or equal to version 3
versions: '>= 3'
注: 構成ファイルの ignore オプションにアクセスできない依存関係を追加した場合でも、Dependabot は、ファイル内のすべての依存関係にアクセスできる場合は、マニフェストまたはロック ファイルでのバージョン更新のみを実行できます。 詳細については、「組織のセキュリティおよび分析設定を管理する」および「Dependabot エラーのトラブルシューティング」を参照してください。
注: pub エコシステムの場合、Dependabot は、以前のバージョンが使用可能な場合でも、更新を試みるバージョンが無視されているときは更新を実行しません。
次の例では、ignore を使用して更新する依存関係をカスタマイズする方法を示します。
特定のバージョン以降の更新プログラムを無視する
ignore:
- dependency-name: "lodash:*"
versions: [ ">=1.0.0" ]
特定のバージョン以降の更新プログラムを無視する
ignore:
- dependency-name: "sphinx"
versions: [ "[1.1,)" ]
パッチ更新プログラムを無視する
ignore:
- dependency-name: "@types/node"
update-types: ["version-update:semver-patch"]
特定バージョンの更新プログラムを無視する
ignore:
- dependency-name: "django*"
versions: [ "11" ]
insecure-external-code-execution
package-ecosystem の値が bundler、mix、および pip であるパッケージ マネージャーは、バージョン更新プロセスの一環としてマニフェスト内の外部コードを実行できます。 これにより、セキュリティが侵害されたパッケージが認証情報を盗んだり、構成済みのレジストリにアクセスしたりすることが可能になる場合もあります。 updates の構成に registries を追加すると、Dependabot は自動的に外部コードの実行を禁止し、バージョンの更新が失敗することがあります。 insecure-external-code-execution を allow に設定することで、この動作をオーバーライドして、bundler、mix、pip パッケージ マネージャーで外部コードを実行できます。
# Allow external code execution when updating dependencies from private registries
version: 2
registries:
ruby-github:
type: rubygems-server
url: https://rubygems.pkg.github.com/octocat/github_api
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
updates:
- package-ecosystem: "bundler"
directory: "/rubygems-server"
insecure-external-code-execution: allow
registries: "*"
schedule:
interval: "monthly"
registries 設定を定義して Dependabot がプライベート パッケージ レジストリにアクセスするのを許可し、同じ updates 構成で insecure-external-code-execution を allow に設定した場合、発生する外部コード実行では、その updates 設定に関連付けられているレジストリ内のパッケージ マネージャーにのみアクセスできます。 最上位の registries 構成で定義されているレジストリへのアクセスは許可されません。
この例では、構成ファイルで、Dependabot が ruby-github プライベート パッケージ レジストリにアクセスするのを許可します。 同じ updates 設定で、insecure-external-code-execution が allow に設定されています。これは、依存関係によって実行されるコードは ruby-github レジストリにのみアクセスし、dockerhub レジストリにはアクセスしないことを指します。
# Using `registries` in conjunction with `insecure-external-code-execution:allow`
# in the same `updates` setting
version: 2
registries:
ruby-github:
type: rubygems-server
url: https://rubygems.pkg.github.com/octocat/github_api
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
dockerhub:
type: docker-registry
url: registry.hub.docker.com
username: octocat
password: ${{secrets.DOCKERHUB_PASSWORD}}
updates:
- package-ecosystem: "bundler"
directory: "/rubygems-server"
insecure-external-code-execution: allow
registries:
- ruby-github # only access to registries associated with this ecosystem/directory
schedule:
interval: "monthly"
insecure-external-code-execution を deny に設定することで、この更新構成に registries 設定があるかどうかにかかわらず、明示的に外部コードの実行を禁止できます。
labels
既定では、Dependabot ではすべての pull request を dependencies ラベル付きで発行します。 複数のパッケージマネージャが定義されている場合、DependabotはそれぞれのPull Requestに追加のラベルを含めます。 これは、その pull request によってどの言語またはエコシステムが更新されるかを示します。たとえば、Gradle の更新には java、Git サブモジュールの更新には submodules というようになります。 Dependabotは、リポジトリ中の必要に応じて自動的にこれらのデフォルトラベルを作成します。
既定のラベルをオーバーライドし、パッケージ マネージャーに対して発行されるすべてのプルリクウェストに代替のラベルを指定するには、labels を使います。 これらのラベルのいずれかがリポジトリで定義されていない場合は無視されます。
既定のラベルを含むすべてのラベルを無効にするには、labels: [ ] を使います。
target-branch を使って既定以外のブランチのバージョン アップデートをチェックしないかぎり、このオプションの設定も、このパッケージ マネージャーのマニフェスト ファイルに対するセキュリティ更新プログラムの pull request に影響します。
# Specify labels for pull requests
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Specify labels for npm pull requests
labels:
- "npm"
- "dependencies"
milestone
パッケージ マネージャーに対して発行されたすべての プルリクウェストをマイルストーンと関連付けるには、milestone を使います。 ラベルではなくマイルストーンの数値識別子を指定する必要があります。 マイルストーンを表示した場合、ページURL の milestone より後の最後の部分が識別子になります。 (例: https://github.com/<org>/<repo>/milestone/3)。
target-branch を使って既定以外のブランチのバージョン アップデートをチェックしないかぎり、このオプションの設定も、このパッケージ マネージャーのマニフェスト ファイルに対するセキュリティ更新プログラムの pull request に影響します。
# Specify a milestone for pull requests
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Associate pull requests with milestone "4"
milestone: 4
open-pull-requests-limit
デフォルトでは、Dependabot は、バージョン更新に対して最大 5 つのプルリクエストをオープンします。 Dependabot からの未解決の プルリクウェストが 5 つあると、Dependabot は、未解決の要求の一部がマージまたは閉じられるまで、新しい要求を開けません。 この制限を変更するには open-pull-requests-limit を使います。 これは、パッケージマネージャーのバージョン更新を一時的に無効にする簡単な方法としても使用できます。
このオプションはセキュリティアップデートに影響を与えません。セキュリティアップデートには、10 件のオープンプルリクエストの内部制限があります。
# Specify the number of open pull requests allowed
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Disable version updates for npm dependencies
open-pull-requests-limit: 0
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
# Allow up to 10 open pull requests for pip dependencies
open-pull-requests-limit: 10
pull-request-branch-name.separator
Dependabot は、プルリクエストごとにブランチを生成します。 各ブランチ名には、dependabot および更新されるパッケージ マネージャーと依存関係が含まれます。 デフォルトでは、これらの部分は / 記号で区切られています (例: dependabot/npm_and_yarn/next_js/acorn-6.4.1)。
別の区切り記号を指定するには pull-request-branch-name.separator を使います。 これは、"-"、_、/ のいずれかです。 ハイフン記号は、引用符で囲む必要があります。囲まない場合、空の YAML リストを開始すると解釈されます。
target-branch を使って既定以外のブランチのバージョン アップデートをチェックしないかぎり、このオプションの設定も、このパッケージ マネージャーのマニフェスト ファイルに対するセキュリティ更新プログラムの pull request に影響します。
# Specify a different separator for branch names
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
pull-request-branch-name:
# Separate sections of the branch name with a hyphen
# for example, `dependabot-npm_and_yarn-next_js-acorn-6.4.1`
separator: "-"
rebase-strategy
デフォルトでは、Dependabotはオープンなプルリクウェストへの変更を検出すると、そのプルリクウェストを自動的にリベースします。 この動作を無効にするには、rebase-strategy を使います。
利用可能なリベース戦略
- 既定の動作を使い、変更が検出されたときに開かれているプルリクウェストをリベースするには
auto。 - 自動リベースを無効にするには
disabled。
rebase-strategy が auto に設定されている場合、Dependabot では次の場合にプルリクウェストのリベースを試みます。
- Dependabot version updates を使用する場合 (スケジュールの実行時に開いている Dependabot プルリクウェストに対して)。
- 閉じた Dependabotプルリクウェストをもう一度開く場合。
- Dependabot 構成ファイルの
target-branchの値を変更する場合。 このフィールドについて詳しくは、「target-branch」を参照してください。 - Dependabot により、ターゲット ブランチへの最近のプッシュ後に Dependabot プルリクウェストが競合していることが検出された場合。
注: Dependabot では、プルリクウェストが閉じられるかマージされるか、ユーザーが Dependabot updates を無効にするまで、プルリクウェストを無期限にリベースし続けます。
rebase-strategy が disabled に設定されている場合、Dependabot ではプルリクウェストのリベースを停止します。
注: この動作は、ターゲット ブランチと競合するプルリクウェストにのみ適用されます。 Dependabot では、rebase-strategy の設定が変更される前に開かれたプルリクウェストと、スケジュールされた実行の一部であるプルリクウェストのリベースが保持されます。
target-branch を使って既定以外のブランチのバージョン アップデートをチェックしないかぎり、このオプションの設定も、このパッケージ マネージャーのマニフェスト ファイルに対するセキュリティ更新プログラムの pull request に影響します。
# Disable automatic rebasing
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Disable rebasing for npm pull requests
rebase-strategy: "disabled"
registries
バージョン更新の実行時に Dependabot がプライベート パッケージ レジストリにアクセスできるようにするには、関係する updates の構成に registries の設定を含める必要があります。
dependabot.yml ファイルには、registries キーを使用できる場所が 2 つあります。
- 必要に応じて、最上位レベルでレジストリとアクセス情報を定義します。
updatesブロック内では、registries: "*"を使って最上位レベルで定義したレジストリの一部またはすべてを使用するように Dependabot に指示できます。
# registries: gradle-artifactory - provides access details for the gradle-artifactory registry
# registries: "*" - allows Dependabot to use all the defined registries specified at the top level
version: 2
registries:
gradle-artifactory:
type: maven-repository
url: https://acme.jfrog.io/artifactory/my-gradle-registry
username: octocat
password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}
updates:
- package-ecosystem: "gradle"
directory: "/"
registries: "*"
schedule:
interval: "monthly"
詳しくは、後の「プライベート レジストリの設定オプション」をご覧ください。
使用可能なオプションの詳細と、プライベート レジストリを構成するときの推奨事項とアドバイスについては、「Dependabot のプライベート レジストリの構成に関するガイダンス」を参照してください。
Dependabot が bundler、mix、pip パッケージ マネージャーを使ってプライベート レジストリの依存関係を更新できるようにするため、外部コードの実行を許可できます。 詳しくは、上の「insecure-external-code-execution」をご覧ください。
# Allow Dependabot to use one of the two defined private registries
# when updating dependency versions for this ecosystem
version: 2
registries:
maven-github:
type: maven-repository
url: https://maven.pkg.github.com/octocat
username: octocat
password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}
npm-npmjs:
type: npm-registry
url: https://registry.npmjs.org
username: octocat
password: ${{secrets.MY_NPM_PASSWORD}}
updates:
- package-ecosystem: "gitsubmodule"
directory: "/"
registries:
- maven-github
schedule:
interval: "monthly"
reviewers
パッケージ マネージャーに対して発行されたすべてのプルリクウェストに個々のレビュー担当者またはレビュー担当者のチームを指定するには、reviewers を使います。 チームを @mentioning している場合と同様オーガニゼーションを含む完全なチーム名を使う必要があります。
target-branch を使って既定以外のブランチのバージョン アップデートをチェックしないかぎり、このオプションの設定も、このパッケージ マネージャーのマニフェスト ファイルに対するセキュリティ更新プログラムの pull request に影響します。
# Specify reviewers for pull requests
version: 2
updates:
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
# Add reviewers
reviewers:
- "octocat"
- "my-username"
- "my-org/python-team"
schedule.day
weekly の更新スケジュールを設定すると、デフォルトでは、Dependabot は月曜日の、リポジトリに設定されたランダムな時刻に、新しいバージョンをチェックします。 更新をチェックする代替日を指定するには、schedule.day を使います。
サポート状況の値
mondaytuesdaywednesdaythursdayfridaysaturdaysunday
# Specify the day for weekly checks
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Check for npm updates on Sundays
day: "sunday"
schedule.time
デフォルトでは、Dependabot は、リポジトリに設定されたランダムな時刻に、新しいバージョンをチェックします。 更新をチェックする別の時間帯を指定するには、schedule.time を使います (形式: hh:mm)。
# Set a time for checks
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Check for npm updates at 9am UTC
time: "09:00"
schedule.timezone
デフォルトでは、Dependabot は、リポジトリに設定されたランダムな時刻に、新しいバージョンをチェックします。 別のタイム ゾーンを指定するには、schedule.timezone を使います。 タイム ゾーン識別子は、iana が管理するタイム ゾーン データベースのものである必要があります。 詳しくは、tz データベースのタイム ゾーンの一覧をご覧ください。
# Specify the timezone for checks
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
time: "09:00"
# Use Japan Standard Time (UTC +09:00)
timezone: "Asia/Tokyo"
target-branch
デフォルトでは、Dependabot はデフォルトのブランチでマニフェストファイルをチェックし、このブランチに対するバージョン更新のプルリクエストを発行します。 マニフェスト ファイルとプルリクエストに別のブランチを指定するには、target-branch を使います。 このオプションを使用すると、このパッケージマネージャーの設定は、セキュリティアップデートのために発行されたプルリクエストに影響しなくなります。
# Specify a non-default branch for pull requests for pip
version: 2
updates:
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
# Raise pull requests for version updates
# to pip against the `develop` branch
target-branch: "develop"
# Labels on pull requests for version updates only
labels:
- "pip dependencies"
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Check for npm updates on Sundays
day: "sunday"
# Labels on pull requests for security and version updates
labels:
- "npm dependencies"
vendor
依存関係を更新するときに、依存関係のベンダリングを Dependabot に指示するには、vendor オプションを使います。 gomod を使っている場合は、Dependabot がこのツールに対するベンダリングを自動的に検出するため、このオプションを使わないでください。
# Configure version updates for both dependencies defined in manifests and vendored dependencies
version: 2
updates:
- package-ecosystem: "bundler"
# Raise pull requests to update vendored dependencies that are checked in to the repository
vendor: true
directory: "/"
schedule:
interval: "weekly"
Dependabot は、リポジトリの特定の場所にあるベンダリングされた依存関係のみを更新します。
| パッケージ マネージャー | ベンダリングされた依存関係のための必須パス | 詳細情報 |
|---|---|---|
bundler | 依存関係は vendor/cache ディレクトリにある必要があります。 他のファイル パスはサポートされません。 | bundle cache ドキュメンテーション |
gomod | パス要件なし (通常、依存関係は vendor ディレクトリにあります) | go mod vendorドキュメンテーション |
versioning-strategy
Dependabot がマニフェスト ファイルを編集してバージョンを更新するときは、複数の異なるバージョン管理戦略を使用できる可能性があります。
| オプション | アクション |
|---|---|
auto | アプリとライブラリを区別してみてください。 アプリには increase を、ライブラリには widen を使用します。 |
increase | 常に、新しいバージョンと一致するように、最低バージョン要件を追加します。 範囲が既に存在する場合は、通常、下限を増やすだけです。 |
increase-if-necessary | 元の制約で新しいバージョンが許可されている場合は制約をそのままにし、それ以外の場合は制約を引き上げます。 |
lockfile-only | ロックファイルを更新するプルリクエストのみを作成します。 パッケージマニフェストの変更が必要になる新しいバージョンは無視します。 |
widen | 可能であれば、許可されるバージョンの要件を広げて、新旧両方のバージョンを含めます。 通常は、許可される最大バージョン要件のみが追加されます。 |
| 該当なし | versioning-strategy パラメーターの構成は、一部のパッケージ マネージャーではまだサポートされていません。 |
次の表では、versioning-strategy の使用方法の例を示します。
| 現在の制約 | 現在のバージョン | 新しいバージョン | 戦略 | 新しい制約 |
|---|---|---|---|---|
| ^1.0.0 | 1.0.0 | 1.2.0 | widen | ^1.0.0 |
| ^1.0.0 | 1.0.0 | 1.2.0 | increase | ^1.2.0 |
| ^1.0.0 | 1.0.0 | 1.2.0 | increase-if-necessary | ^1.0.0 |
| ^1.0.0 | 1.0.0 | 2.0.0 | widen | >=1.0.0 <3.0.0 |
| ^1.0.0 | 1.0.0 | 2.0.0 | increase | ^2.0.0 |
| ^1.0.0 | 1.0.0 | 2.0.0 | increase-if-necessary | ^2.0.0 |
サポートされているパッケージ マネージャーでこの動作を変更するには、versioning-strategy オプションを使います。
target-branch を使って既定以外のブランチのバージョン アップデートをチェックしないかぎり、このオプションの設定も、このパッケージ マネージャーのマニフェスト ファイルに対するセキュリティ更新プログラムの pull request に影響します。
利用できる更新戦略:
| エコシステム | サポートされているバージョン管理戦略 | 既定の戦略 |
|---|---|---|
bundler | auto、increase、increase-if-necessary、lockfile-only | auto |
cargo | auto、lockfile-only | auto |
composer | auto、increase、increase-if-necessary、lockfile-only、widen | auto |
docker | 該当なし | 該当なし |
github-actions | 該当なし | 該当なし |
gitsubmodule | 該当なし | 該当なし |
gomod | 該当なし | 該当なし |
gradle | 該当なし | 該当なし |
maven | 該当なし | 該当なし |
mix | auto、lockfile-only | auto |
npm | auto、increase、increase-if-necessary、lockfile-only、widen | auto |
nuget | 該当なし | 該当なし |
pip | auto、increase、increase-if-necessary、lockfile-only | auto |
pub | auto、increase、increase-if-necessary、widen | auto |
terraform | 該当なし | 該当なし |
注: N/A は、パッケージ マネージャーで versioning-strategy パラメーターの構成がまだサポートされていないことを示します。 戦略コードはオープンソースであるため、特定のエコシステムで新しい戦略をサポートしたい場合は、いつでも https://github.com/dependabot/dependabot-core/ で プルリクウェストをお送りください。
# Example configuration for customizing the manifest version strategy
version: 2
updates:
- package-ecosystem: "composer"
directory: "/"
schedule:
interval: "weekly"
# Increase the version requirements for Composer only when required
versioning-strategy: increase-if-necessary
プライベートレジストリの構成オプション
最上位の registries キーは省略可能です。 このキーでは、Dependabot がプライベートパッケージレジストリにアクセスするために使用する認証の詳細を指定できます。
git の type を指定することで、GitLab または Bitbucket によってホストされるプライベート パッケージ レジストリに Dependabot アクセス権を付与できます。 詳細については、gitを参照してください。
注: プライベート ネットワーク上のファイアウォールの背後にあるプライベート レジストリは、次のエコシステムでサポートされています。
- Bundler
- ドッカー
- グレイドル
- メイヴン
- npm
- Nuget
- Python
- Yarn
registries キーの値は連想配列で、その各要素は、特定のレジストリを指定するキーと、そのレジストリへのアクセスに必要な設定を指定する連想配列の値により構成されます。 次の dependabot.yml ファイルでは、ファイルの registries セクションで dockerhub として指定されたレジストリが構成された後、ファイルの updates セクションでそれが参照されています。
# Minimal settings to update dependencies in one private registry
version: 2
registries:
dockerhub: # Define access for a private registry
type: docker-registry
url: registry.hub.docker.com
username: octocat
password: ${{secrets.DOCKERHUB_PASSWORD}}
updates:
- package-ecosystem: "docker"
directory: "/docker-registry/dockerhub"
registries:
- dockerhub # Allow version updates for dependencies in this registry
schedule:
interval: "monthly"
以下のオプションを使用して、アクセス設定を指定します。 レジストリの設定には、type と url、そして通常は username と password の組み合わせまたは token を含める必要があります。
| オプション | 説明 |
|---|---|
type | レジストリのタイプを指定します。 使用できるレジストリの種類について詳しくは、「registries」をご覧ください。プライベート レジストリの具体的な構成について詳しくは、「プライベート レジストリの設定オプション」をご覧ください。 |
url | このレジストリの依存関係にアクセスするために使用する URL。 プロトコルはオプションです。 指定しないと、https:// が想定されます。 Dependabot が必要に応じて末尾のスラッシュを追加または無視します。 |
username | Dependabot がレジストリにアクセスするために使用するユーザ名。username は、アカウントのユーザー名またはメール アドレスです。 |
password | 指定したユーザのパスワードを含む Dependabot シークレットへのリファレンス。 詳しくは、「Dependabot のプライベート レジストリへのアクセスの構成」を参照してください。password はユーザー名が指定したアカウントのパスワードです。 アカウントが GitHub アカウントの場合は、パスワードの代わりに GitHub personal access token を使用できます。 |
key | このレジストリへのアクセスキーを含むDependabotシークレットへの参照 詳しくは、「Dependabot のプライベート レジストリへのアクセスの構成」を参照してください。 |
token | このレジストリへのアクセストークンを含む Dependabot シークレットへのリファレンス。 詳しくは、「Dependabot のプライベート レジストリへのアクセスの構成」を参照してください。token は外部システムにアクセス トークンを提供するために使用します。GitHub personal access token を提供するために使用しないでください。 GitHub personal access token を使用する場合は、パスワードとして指定する必要があります。 |
replaces-base | レジストリ では、ブール値が true の場合、Dependabot ではその特定のエコシステムのベース URL ではなく、指定された URL を使って依存関係を解決します。 たとえば、type: python-index であるレジストリでは、ブール値が true の場合、pip では Python Package Index のベース URL (既定では https://pypi.org/simple) ではなく、指定された URL を使って依存関係を解決します。 |
指定する type の構成ごとに必要な設定を指定する必要があります。 タイプによっては、複数の接続方法を使用できます。 以下のセクションでは、各 type に使う必要がある設定の詳細を説明します。
使用可能なオプションの詳細と、プライベート レジストリを構成するときの推奨事項とアドバイスについては、「Dependabot のプライベート レジストリの構成に関するガイダンス」を参照してください。
composer-repository
composer-repository タイプは、ユーザー名とパスワードをサポートします。 アカウントが GitHub アカウントの場合は、パスワードの代わりに GitHub personal access token を使用できます。
このレジストリの種類は、url オプションで指定されたパスのプレフィックスと一致します。 つまり、同じホストに複数の資格情報を指定でき、これを使用して異なるパスにアクセスできます。 ただし、同じホストに複数のレジストリがない場合は、レジストリへのすべてのパスが資格情報を受け取るように、url からパスを省略することをお勧めします。
registries:
composer:
type: composer-repository
url: https://repo.packagist.com/example-company/
username: octocat
password: ${{secrets.MY_PACKAGIST_PASSWORD}}
docker-registry
Dependabot は、OCI コンテナー レジストリ仕様を実装するすべてのコンテナー レジストリで動作します。詳しくは、「https://github.com/opencontainers/distribution-spec/blob/main/spec.md」を参照してください。 Dependabot では、中央トークン サービスまたは HTTP 基本認証を介したプライベート レジストリへの認証がサポートされています。詳しくは、ドッカー ドキュメントのトークン認証仕様と ウィキペディアの基本アクセス認証に関するページを参照してください。
docker-registry タイプは、ユーザー名とパスワードをサポートします。 アカウントが GitHub アカウントの場合は、パスワードの代わりに GitHub personal access token を使用できます。
このレジストリの種類は、url オプションで指定されたパスのプレフィックスと一致します。 つまり、同じホストに複数の資格情報を指定でき、これを使用して異なるパスにアクセスできます。 ただし、同じホストに複数のレジストリがない場合は、レジストリへのすべてのパスが資格情報を受け取るように、url からパスを省略することをお勧めします。
registries:
dockerhub:
type: docker-registry
url: https://registry.hub.docker.com
username: octocat
password: ${{secrets.MY_DOCKERHUB_PASSWORD}}
replaces-base: true
docker-registry タイプは、静的な AWS 資格情報を使ってプライベート アマゾン ECR からプルするためにも使用できます。
registries:
ecr-docker:
type: docker-registry
url: https://1234567890.dkr.ecr.us-east-1.amazonaws.com
username: ${{secrets.ECR_AWS_ACCESS_KEY_ID}}
password: ${{secrets.ECR_AWS_SECRET_ACCESS_KEY}}
replaces-base: true
git
git タイプは、ユーザー名とパスワードをサポートします。 アカウントが GitHub アカウントの場合は、パスワードの代わりに GitHub personal access token を使用できます。
registries:
github-octocat:
type: git
url: https://github.com
username: x-access-token
password: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
hex-organization
hex-organization タイプは、Organization とキーをサポートします。
このレジストリの種類は、url オプションで指定されたパスのプレフィックスと一致します。 つまり、同じホストに複数の資格情報を指定でき、これを使用して異なるパスにアクセスできます。 ただし、同じホストに複数のレジストリがない場合は、レジストリへのすべてのパスが資格情報を受け取るように、url からパスを省略することをお勧めします。
registries:
github-hex-org:
type: hex-organization
organization: github
key: ${{secrets.MY_HEX_ORGANIZATION_KEY}}
hex-repository
hex-repository タイプでは認証キーがサポートされています。
repo は必須フィールドです。これは、依存関係宣言で使用されるリポジトリの名前と一致する必要があります。
public-key-fingerprint は省略可能な構成フィールドで、Hex リポジトリの公開キーのフィンガー プリントを表します。 public-key-fingerprint は、プライベート リポジトリとの信頼を確立するために Hex で使用されます。 public-key-fingerprint フィールドはプレーン テキストで一覧表示することも、Dependabot シークレットとして格納することもできます。
registries:
github-hex-repository:
type: hex-repository
repo: private-repo
url: https://private-repo.example.com
auth-key: ${{secrets.MY_AUTH_KEY}}
public-key-fingerprint: ${{secrets.MY_PUBLIC_KEY_FINGERPRINT}}
maven-repository
maven-repository タイプは、ユーザー名とパスワードをサポートします。 アカウントが GitHub アカウントの場合は、パスワードの代わりに GitHub personal access token を使用できます。
このレジストリの種類は、url オプションで指定されたパスのプレフィックスと一致します。 つまり、同じホストに複数の資格情報を指定でき、これを使用して異なるパスにアクセスできます。 ただし、同じホストに複数のレジストリがない場合は、レジストリへのすべてのパスが資格情報を受け取るように、url からパスを省略することをお勧めします。
registries:
maven-artifactory:
type: maven-repository
url: https://acme.jfrog.io/artifactory/my-maven-registry
username: octocat
password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}
npm-registry
npm-registry タイプは、ユーザー名とパスワード、またはトークンをサポートします。 アカウントが GitHub アカウントの場合は、パスワードの代わりに GitHub personal access token を使用できます。
ユーザー名とパスワードを使うとき、.npmrc の認証トークンには base64 でエンコードされた _password を含めることができます。ただし、Dependabot の構成ファイルで参照されるパスワードは、元の (エンコードされていない) パスワードである必要があります。
注: npm.pkg.github.com を使用する場合は、パスを含めないでください。 代わりに、パスのない https://npm.pkg.github.com URL を使用してください。
registries:
npm-npmjs:
type: npm-registry
url: https://registry.npmjs.org
username: octocat
password: ${{secrets.MY_NPM_PASSWORD}} # Must be an unencoded password
replaces-base: true
registries:
npm-github:
type: npm-registry
url: https://npm.pkg.github.com
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
replaces-base: true
セキュリティ上の理由から、Dependabot は環境変数を設定しません。 Yarn (v2 以降) では、アクセスされた環境変数が設定されている必要があります。 .yarnrc.yml ファイル内の環境変数にアクセスするときは、${ENV_VAR-fallback}や ${ENV_VAR:-fallback} などのフォールバック値を指定する必要があります。 詳しくは、Yarn ドキュメントの Yarnrc ファイルを参照してください。
nuget-feed
nuget-feed タイプは、ユーザー名とパスワード、またはトークンをサポートします。 アカウントが GitHub アカウントの場合は、パスワードの代わりに GitHub personal access token を使用できます。
registries:
nuget-example:
type: nuget-feed
url: https://nuget.example.com/v3/index.json
username: octocat@example.com
password: ${{secrets.MY_NUGET_PASSWORD}}
registries:
nuget-azure-devops:
type: nuget-feed
url: https://pkgs.dev.azure.com/.../_packaging/My_Feed/nuget/v3/index.json
username: octocat@example.com
password: ${{secrets.MY_AZURE_DEVOPS_TOKEN}}
python-index
python-index タイプは、ユーザー名とパスワード、またはトークンをサポートします。 アカウントが GitHub アカウントの場合は、パスワードの代わりに GitHub personal access token を使用できます。
このレジストリの種類は、url オプションで指定されたパスのプレフィックスと一致します。 つまり、同じホストに複数の資格情報を指定でき、これを使用して異なるパスにアクセスできます。 ただし、同じホストに複数のレジストリがない場合は、レジストリへのすべてのパスが資格情報を受け取るように、url からパスを省略することをお勧めします。
registries:
python-example:
type: python-index
url: https://example.com/_packaging/my-feed/pypi/example
username: octocat
password: ${{secrets.MY_BASIC_AUTH_PASSWORD}}
replaces-base: true
registries:
python-azure:
type: python-index
url: https://pkgs.dev.azure.com/octocat/_packaging/my-feed/pypi/example
username: octocat@example.com
password: ${{secrets.MY_AZURE_DEVOPS_TOKEN}}
replaces-base: true
rubygems-server
rubygems-server タイプは、ユーザー名とパスワード、またはトークンをサポートします。 アカウントが GitHub アカウントの場合は、パスワードの代わりに GitHub personal access token を使用できます。
このレジストリの種類は、url オプションで指定されたパスのプレフィックスと一致します。 つまり、同じホストに複数の資格情報を指定でき、これを使用して異なるパスにアクセスできます。 ただし、同じホストに複数のレジストリがない場合は、レジストリへのすべてのパスが資格情報を受け取るように、url からパスを省略することをお勧めします。
registries:
ruby-example:
type: rubygems-server
url: https://rubygems.example.com
username: octocat@example.com
password: ${{secrets.MY_RUBYGEMS_PASSWORD}}
replaces-base: true
registries:
ruby-github:
type: rubygems-server
url: https://rubygems.pkg.github.com/octocat/github_api
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
replaces-base: true
terraform-registry
terraform-registry タイプは、トークンをサポートします。
registries:
terraform-example:
type: terraform-registry
url: https://terraform.example.com
token: ${{secrets.MY_TERRAFORM_API_TOKEN}}
ベータ レベルのエコシステムのサポートを有効にする
enable-beta-ecosystems
既定では、Dependabot は、完全にサポートされているエコシステムについてのみ、依存関係マニフェストとロック ファイルを更新します。 まだ一般提供されていないエコシステムの更新にオプトインするには、enable-beta-ecosystems フラグを使います。
現在、ベータ版のエコシステムはありません。
# Configure beta ecosystem
version: 2
enable-beta-ecosystems: true
updates:
- package-ecosystem: "beta-ecosystem"
directory: "/"
schedule:
interval: "weekly"