dependabot.yml ファイルの構成オプション

dependabot.yml ファイルについて

Dependabot の構成ファイルである dependabot.yml では、YAML 構文を使います。 YAML を初めて使う場合、詳しくは「YAML を 5 分で学習する」をご覧ください。

このファイルは、既定のブランチにリポジトリの .github ディレクトリに保存する必要があります。 dependabot.yml ファイルを追加または更新すると、バージョン更新の即時チェックがトリガーされます。 詳細と例については、「Dependabot のバージョン アップデートの設定」をご覧ください。

セキュリティアップデートに影響するオプションは、次にセキュリティアラートがセキュリティアップデートのための pull request をトリガーするときにも使用されます。 詳しくは、「Configuring Dependabot security updates (Dependabot セキュリティ アップデートの構成)」を参照してください。

dependabot.yml ファイルには、version と updates の 2 つの必須の最上位キーがあります。 必要に応じて、最上位の registries キーを含めることができます。 このファイルは version: 2 で始まる必要があります。

実際の dependabot.yml ファイルの例については、「Dependabot 自身の構成ファイル」を参照してください。

dependabot.yml ファイルの構成オプション

最上位の updates キーは必須です。 これを使用することで、Dependabot がバージョンやプロジェクトの依存性を更新する方法を設定できます。 各エントリは、特定のパッケージマネージャーの更新設定を行います。 次のオプションを使用できます。

オプション	必須	セキュリティ更新プログラム	バージョン アップデート	説明
package-ecosystem				使用するパッケージマネージャー
directory				パッケージマニフェストの場所
directories				パッケージ マニフェストの場所 (複数のディレクトリ)
schedule.interval				更新を確認する頻度
allow				許可する更新をカスタマイズする
assignees				pull request のアサイン担当者
commit-message				コミットメッセージの環境設定
enable-beta-ecosystems				ベータ レベルのサポートを備えたエコシステムを有効にする
groups				特定の依存関係のグループ更新
ignore		ignore をご覧ください。	ignore をご覧ください。	特定の依存関係またはバージョンを無視する
insecure-external-code-execution				マニフェストファイル内でコードの実行を許可または拒否する
labels				pull request に設定するラベル
milestone				pull request に設定するマイルストーン
open-pull-requests-limit				バージョン更新時のオープンな pull request 数を制限する
pull-request-branch-name.separator				pull request ブランチ名の区切り文字を変更する
rebase-strategy				自動リベースを無効にする
registries				Dependabot がアクセスできるプライベートリポジトリ
reviewers				pull request のレビュー担当者
schedule.day				更新を確認する曜日
schedule.time				更新を確認する時刻 (hh:mm)
schedule.timezone				時刻のタイムゾーン（ゾーン識別子）
target-branch				pull request を作成するブランチ
vendor				ベンダーまたはキャッシュされた依存関係を更新する
versioning-strategy				マニフェストのバージョン要件の更新方法

これらのオプションは、次のようなカテゴリに幅広く適合しています。

• すべての構成に含める必要がある基本的な設定オプション: package-ecosystem、directory または directories、schedule.interval。
• 更新スケジュールをカスタマイズするためのオプション: schedule.time、schedule.timezone、schedule.day。
• 更新される依存関係を制御するオプション: allow、groups、ignore、vendor。
• メタデータを pull request に追加するオプション: reviewers、assignees、labels、milestone。
• pull request の動作を変更するオプション: target-branch、versioning-strategy、commit-message、rebase-strategy、pull-request-branch-name.separator。

さらに、open-pull-requests-limit オプションは、Dependabot で開くことのできるバージョン更新の pull request の最大数を変更します。

package-ecosystem

必須。 Dependabot で新しいバージョンを監視するパッケージ マネージャーごとに、1 つの package-ecosystem 要素を追加します。 リポジトリには、これらの各パッケージマネージャーの依存関係マニフェストまたはロックファイルも含まれている必要があります。

サポートするパッケージマネージャーに対してベンダリングを有効にする場合、ベンダリングされた依存関係が必須ディレクトリに存在する必要があります。 詳しくは、後の「vendor」をご覧ください。

バージョン更新の実行時に Dependabot がプライベート パッケージ レジストリにアクセスできるようにしたい場合は、構成ファイルに registries の設定を含めることができます。 詳しくは、「registries」をご覧ください。

パッケージ マネージャー	YAML値	サポートされているバージョン	バージョン アップデート	セキュリティ更新プログラム	プライベートリポジトリ	プライベート レジストリ	ベンダー
Bundler	bundler	v2
Cargo	cargo	v1
Composer	composer	v1, v2
開発コンテナー	devcontainers	適用できません
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	6.12.0 以下
pip	pip	v21.1.2
pipenv	pip	<= 2021-05-29
pip-compile	pip	6.1.0
pnpm	npm	v7、v8、v9
poetry	pip	v1
pub	pub	v2
Swift	swift	v5				(git only)
Terraform	terraform	>= 0.13, <= 1.8.x					適用なし
yarn	npm	v1、v2、v3

Dependabot security updates のエコシステム サポートの詳細については、「依存関係グラフでパッケージ エコシステムをサポート」も参照してください。

Cargo

プライベート レジストリのサポートには cargo レジストリが含まれているため、Dependabot を使用して Rust の依存関係を最新の状態に保つことができます。 詳細については、「Dependabot のプライベート レジストリの構成に関するガイダンス」を参照してください。

開発コンテナー

dependabot.yml ファイル内で devcontainers を package-ecosystem として使用して、devcontainer.json 構成ファイルの機能を更新できます。 このサポートの詳細と構成ファイルの例については、開発 コンテナー ドキュメントの「Dependabot 統合 の一般提供」を参照してください。

開発コンテナーは、Codespaces など、いくつかのツールとサービスで使用されます。 機能とサポートされているサービスの詳細については、開発コンテナー ドキュメントの「機能」と「サポート ツールとサービス」をそれぞれ参照してください。

このアップデーターにより、関連付けられた devcontainer.json ファイル内の最新の major バージョンに機能が固定されます。 開発コンテナーにロックファイルがある場合、そのファイルも更新されます。 ロックファイルの仕様の詳細については、devcontainers/spec リポジトリ内の「ロックファイル」を参照してください。

任意の有効な開発コンテナーの場所にある機能は、1 つのプル リクエストで更新されます。 開発コンテナーの仕様についての詳細は、開発コンテナー ドキュメントの「仕様」を参照してください。

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

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

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

Dependabot は、依存関係の pom.xml ファイルの情報を使用して、更新 pull request にリリース情報へのリンクを追加します。 pom.xml ファイルでこの情報が省略されている場合、Dependabot pull request に含めることはできません。「Dependabot の更新のための Java パッケージの最適化」を参照してください。

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

Maven

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

Dependabot は、依存関係の pom.xml ファイルの情報を使用して、更新 pull request にリリース情報へのリンクを追加します。 pom.xml ファイルでこの情報が省略されている場合、Dependabot pull request に含めることはできません。「Dependabot の更新のための Java パッケージの最適化」を参照してください。

NuGet CLI

Dependabot は NuGet CLI を実行しませんが、バージョン 6.8.0 までのほとんどの機能をサポートしています。

pip と pip-compile

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

pub

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

非公開でホストされたパブ リポジトリを使用する場合は、Dependabot を使用して、Dart の依存関係を最新の状態に保つことができます。 Dependabot にプライベート GitHub 依存関係へのアクセスを許可する方法については、「Dependabot によるプライベート依存関係へのアクセスを許可する」を参照してください。

Swift

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

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 以外のすべてのエコシステムで、リポジトリのルートに対する相対ディレクトリを定義します。

directory の代わりに directories を使用して、複数のディレクトリの一覧に同じ構成を適用できます。 directory または directories エントリは一意である必要があり、同じエコシステムと target-branch を持つブロック内の directory または directories エントリと重複することはできません。 複数のディレクトリを指定するブロックと、1 つのディレクトリのみを指定する別のディレクトリを有することはできますが、両方のキーを同じブロック内に存在することはできません。 詳細については、「directories」を参照してください。

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"

directories

必須。 各パッケージ マネージャーのパッケージ マニフェストの場所を定義する必要があります。 GitHub Actions 以外のすべてのエコシステムで、リポジトリのルートに対する相対ディレクトリを定義します。 directories オプションには、ディレクトリを表す文字列の一覧が含まれています。

# Specify locations of manifest files for each package manager using `directories`

version: 2
updates:
  - package-ecosystem: "bundler"
    directories:
      - "/frontend"
      - "/backend"
      - "/admin"
    schedule:
      interval: "weekly"

directory の代わりに directories を使用して、複数のディレクトリの一覧に同じ構成を適用できます。 directory または directories エントリは一意である必要があり、同じエコシステムと target-branch を持つブロック内の directory または directories エントリと重複することはできません。 複数のディレクトリを指定するブロックと、1 つのディレクトリのみを指定する別のディレクトリを有することはできますが、両方のキーを同じブロック内に存在することはできません。

directory、directories、または両方の組み合わせを使用することは、すべて有効なアプローチです。 要件に合わせて構成を調整する必要があります。 複数のディレクトリにまったく同じ構成を適用したり、複数のディレクトリにまたがる依存関係の更新をグループ化したりする場合は directories を使用し、1 つのディレクトリのみに構成を適用したり、または各ディレクトリに異なる構成を適用したりする場合は、directory を使用することをお勧めします。

# Specify locations of manifest files for each package manager using both `directories` and `directory`

version: 2
updates:
  - package-ecosystem: "bundler"
    directories:
      - "/frontend"
      - "/backend"
      - "/admin"
    schedule:
      interval: "weekly"
  - package-ecosystem: "bundler"
    directory: "/"
    schedule:
      interval: "daily"

# Specify the root directory and directories that start with "lib-", using globbing, for locations of manifest files

version: 2
updates:
  - package-ecosystem: "composer"
    directories:
      - "/"
      - "/lib-*"
    schedule:
      interval: "weekly"

# Specify the root directory and directories in the root directory as the location of manifest files using the wildcard character

version: 2
updates:
  - package-ecosystem: "composer"
    directories:
      - "*"
    schedule:
      interval: "weekly"

# Specify all directories from the current layer and below recursively, using globstar, for locations of manifest files

version: 2
updates:
  - package-ecosystem: "composer"
    directories:
      - "**/*"
    schedule:
      interval: "weekly"

マルチディレクトリのサポートは、pull request での更新のグループ化とは異なります。

• dependabot.yml ファイルの directories オプションを使用すると、複数のディレクトリに Dependabot updates を同時に適用できます。
• dependabot.yml ファイルの groups オプションは、Dependabot が同じ単一の pull request に配置するための依存関係のセット (パッケージ マネージャーごと) を作成します。

リポジトリで両方の機能を使用する場合は、上記の 2 つのキーを使用して、これらの機能を個別かつ明示的に有効にする必要があります。 グループ化の詳細については、「groups」を参照してください。

schedule.interval

必須。 各パッケージマネージャーに対して、新しいバージョンを確認する頻度を定義する必要があります。 デフォルトでは、Dependabotは設定ファイル中のすべての更新を適用する時間をランダムに割り当てます。 特定の日時を設定するには、schedule.time と schedule.timezone を使うことができます。

間隔の型	頻度
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"

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 を使います。

• dependency-type — 特定の種類の依存関係の更新を許可するために使います。

  依存関係の種類	パッケージマネージャーによるサポート	更新の許可
  direct	すべて	明示的に定義されたすべての依存関係。
  indirect	bundler、pip、composer、cargo、gomod	直接依存関係の依存関係 (サブ依存関係、または一時的依存関係とも呼ばれる)。
  all	すべて	明示的に定義されたすべての依存関係。 bundler、pip、composer、cargo、gomod の場合は、直接依存関係の依存関係も。
  production	bundler、composer、mix、maven、npm、pip (すべてのマネージャーではない)	"運用依存関係グループ" の依存関係のみ。
  development	bundler、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 を使って、パッケージ マネージャーに対して発行されたすべての pull request の個々の担当者を指定します。

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 オプションを使って、環境設定を明示的に指定します。 この設定は、pull request のタイトルにも影響します。

明示的に設定したかリポジトリ履歴から自動検出されたかに関係なく、コミット メッセージに基づいて pull request のタイトルを設定します。

サポートされているオプション

• prefix は、すべてのコミット メッセージのプレフィックスを指定し、PR タイトルの先頭にも追加されます。 コミット メッセージのプレフィックスを指定すると、定義されたプレフィックスが文字、数字、終わりかっこ、または右角かっこで終われば、GitHub によって、定義されたプレフィックスとコミット メッセージの間にコロンを自動的に追加されます。 つまり、たとえば、プレフィックスを空白で終えた場合、プレフィックスとコミット メッセージの間にコロンは追加されません。 次のコード スニペットでは、同じ構成ファイル内の両方の例を示します。

• prefix-development では、開発依存関係グループ内の依存関係を更新するすべてのコミット メッセージに個別のプレフィックスを指定します。 このオプションの値を指定すると、prefix は、プロダクション依存関係グループの依存関係の更新にのみ使われます。 これは、bundler、composer、mix、maven、npm、pip でサポートされています

• include: "scope" では、すべてのプレフィックスの後に、コミットで更新される依存関係の種類 (deps または deps-dev) が続くことを指定します。

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"

上記の例と同じ構成を使用する場合、pip 開発依存関係グループの requests ライブラリを更新すると、次のコミット メッセージが生成されます。

pip dev: bump requests from 1.0.0 to 1.0.1

groups

dependabot.yml ファイルを使用して、Dependabot version updates と Dependabot security updates をグループ化する個別のルールを作成できます。

既定では、Dependabot によって、新しいバージョンに更新する必要がある依存関係ごとに 1 つの pull request が生成されます。 groups を使って (パッケージ マネージャーごとに) 依存関係のセットを作成し、Dependabot が 1 つの pull request を開いて複数の依存関係を同時に更新できるようにします。

また、更新プログラムが特定のエコシステムに与える影響に基づいてグループ化設定を指定し、セマンティック バージョン管理 (SemVer) にフォローすることもできます。 つまり、たとえば、すべてのパッチ更新プログラムをグループ化できます。 このアプローチは、Dependabot が作成する pull request をできるだけ少なくすると同時に、問題点の原因となる可能性のある変更点を誤って承諾する可能性を減らすのに役立ちます。 パッケージが SemVer に従っている場合、マイナー更新プログラムとパッチ更新プログラムが下位互換性を持つ可能性が高くなります (ただし、保証はありません)。

グループを最初に構成するときは、pull request タイトルとブランチ名に表示されるグループ名と、グループルールがバージョン更新またはセキュリティ アップデートに適用されるかどうかを指定します。 その後、グループに特定の依存関係を含めたりグループから除外したりするその他のオプションを定義できます。 グループを定義する場合、patterns、exclude-patterns、dependency-type、または update-types のオプション、あるいはそれらの任意の組み合わせを使用する必要があります。

オプション	説明
applies-to	グループ内のルールをバージョン更新またはセキュリティ アップデートに適用するかどうかを指定するために使用します。 applies-to には、version-updates または security-updates を指定できます。
dependency-type	グループに含める依存関係の TYPE を指定するために使用します。 dependency-type には、development または production を指定できます。
patterns	次に、グループに含める依存関係の名前 (1 つまたは複数) と一致する (文字列) を定義して、それらの依存関係をグループに含めるために使用します。
exclude-patterns	特定の依存関係をグループから除外するために使用します。 依存関係がグループから除外されている場合、Dependabot は引き続き単一の pull request を生成して、依存関係を最新バージョンに更新します。
update-types	グループに含めるセマンティック バージョン管理レベルを指定するために使用します。 有効な値は minor、patch、major です。

この applies-to キーは、グループ化ルールのセットがバージョンの更新プログラムとセキュリティ アップデート プログラムのどちらを対象とするかを指定するために使用されます。 applies-to キーの使用はオプションです。 applies-to キーがグループ化ルールのセットに存在しない場合は、後方互換対応を考慮して既定で version-updates が使用されます。 バージョン更新プログラムとセキュリティ アップデートプログラムの両方に、1 つのグループ化ルール セットを適用することはできません。 代わりに、同じ条件を使用してバージョン更新プログラムとセキュリティ アップデート プログラムの両方をグループ化する場合は、個別に名前を付けた 2 つのルール セットを定義する必要があります。 これを行うには、エコシステムとディレクトリのグループ構成ブロックをコピーし、ルールの各セットに異なる名前を付けます。

Dependabot は、dependabot.yml ファイルに表示される順序でグループを作成します。 依存関係の更新が複数のグループに属している可能性がある場合、一致する最初のグループにのみ割り当てられます。

依存関係がグループに属していない場合、Dependabot は引き続き 1 つの pull request を発生させ、依存関係を通常どおり最新バージョンに更新します。 GitHub は、グループが空の場合にログに報告します。 詳細については、「Dependabot が依存関係のセットを 1 つの pull request にグループ化できない」を参照してください。

スケジュールされた更新が実行されると、Dependabot は、次のルールを使用してグループ化された更新の pull request を更新します。

• 同じ依存関係をすべて同じバージョンに更新する必要がある場合、Dependabot はブランチをリベースします。
• 同じ依存関係をすべて更新する必要があるが、1 つ以上の依存関係で新しいバージョンを使用できる場合、Dependabot はその pull request を閉じて、新しいものを作成します。
• 更新対象の依存関係が変更されている場合 (たとえば、グループ内の別の依存関係で更新プログラムを使用できる場合など)、Dependabot はその pull request を閉じて、新しいものを作成します。

グループ化されたバージョン更新とセキュリティ アップデートの pull request は、コメント コマンドを使用して管理することもできます。これは、Dependabot に命令する pull request につけることができる短いコメントです。 詳しくは、「依存関係の更新に関するPull Requestを管理する」を参照してください。

例 1

dependabot.yml ファイル構成では、グループに特定の依存関係を含める patterns および dependency-type オプションや、グループから依存関係 (または複数の依存関係) を除外する exclude-patterns が使用されます。グループ化ルールは、applies-to キーが存在しないため、既定でバージョン更新にのみ適用されます。

# `dependabot.yml` file using the `dependency-type` option to group updates
# in conjunction with `patterns` and `exclude-patterns`.
# Grouping rules default to applying to version updates only, since
# the `applies-to` key is absent.

groups:
  production-dependencies:
    dependency-type: "production"
  development-dependencies:
    dependency-type: "development"
    exclude-patterns:
    - "rubocop*"
  rubocop:
    patterns:
    - "rubocop*"

例 2

依存関係のグループを作成するように変更された、カスタマイズされた Bundler 構成を含む dependabot.yml ファイル。 この構成では、依存関係をグループに含めるために、依存関係の名前 (または複数の依存関係) と一致する patterns (文字列) を指定します。グループ化ルールは、applies-to: version-updates が使用されているため、バージョン更新にのみ適用されます。

# `dependabot.yml` file with customized Bundler configuration
# In this example, the name of the group is `dev-dependencies`, and
# only the `patterns` and `exclude-patterns` options are used.
# Grouping rules apply to version updates only.

version: 2
updates:
  # Keep bundler dependencies up to date
  - package-ecosystem: "bundler"
    directories:
      - "/frontend"
      - "/backend"
      - "/admin"
    schedule:
      interval: "weekly"
    # Create a group of dependencies to be updated together in one pull request
    groups:
       # Specify a name for the group, which will be used in pull request titles
       # and branch names
       dev-dependencies:
          # Define patterns to include dependencies in the group (based on
          # dependency name)
          applies-to: version-updates # Applies the group rule to version updates
          patterns:
            - "rubocop" # A single dependency name
            - "rspec*"  # A wildcard string that matches multiple dependency names
            - "*"       # A wildcard that matches all dependencies in the package
                        # ecosystem. Note: using "*" may open a large pull request
          # Define patterns to exclude dependencies from the group (based on
          # dependency name)
          exclude-patterns:
            - "gc_ruboconfig"
            - "gocardless-*"

例 3

dependabot.yml ファイルは、解決できる最高のバージョンが minor または patch であるパターン @angular* に一致するパッケージがグループ化されるように構成されています。 Dependabot は、パターンに一致しないパッケージ、あるいは minor または patch バージョンに更新されないパッケージに対して個別の pull request を作成します。グループ化ルールは、applies-to: version-updates が使用されているため、バージョン更新にのみ適用されます。

# `dependabot.yml` file using the `update-types` option to group updates.
# Any packages matching the pattern @angular* where the highest resolvable
# version is minor or patch will be grouped together.
# Grouping rules apply to version updates only.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      angular:
        applies-to: version-updates
        patterns:
        - "@angular*"
        update-types:
        - "minor"
        - "patch"

例 4

dependabot.yml ファイルでは、ignore 条件を使用して、@angular* パッケージの major バージョンに対する更新を除外します。バージョン更新用とセキュリティ アップデート用の 2 つのグループ化ルールが指定されています。

# `dependabot.yml` file using the `update-types` option to group updates
# in conjunction with an `ignore` condition. If you do not want updates
# to `major` versions of `@angular*` packages, you can specify an `ignore` condition.
# Grouping rules for both version updates and security updates are specified.

groups:
  angular:
    applies-to: version-updates
    patterns:
    - "@angular*"
    update-types:
    - "minor"
    - "patch"
  minor-and-patch:
    applies-to: security-updates
    patterns:
    - "@angular*"
    update-types:
    - "patch"
    - "minor"
ignore:
  - dependency-name: "@angular*"
    update-types: ["version-update:semver-major"]

マルチディレクトリのサポートは、pull request での更新のグループ化とは異なります。

• dependabot.yml ファイルの directories オプションを使用すると、複数のディレクトリに Dependabot updates を同時に適用できます。
• dependabot.yml ファイルの groups オプションは、Dependabot が同じ単一の pull request に配置するための依存関係のセット (パッケージ マネージャーごと) を作成します。

リポジトリで両方の機能を使用する場合は、上記の 2 つのキーを使用して、これらの機能を個別かつ明示的に有効にする必要があります。 マルチディレクトリのサポートの詳細については、「directories」を参照してください。

ignore

既定では、マニフェストで明示的に定義されているすべての依存関係が Dependabot によって最新の状態に保たれます。 さらに、Dependabot セキュリティ更新によって、ロック ファイルに定義されている脆弱な依存関係も更新されます。 保守管理する依存関係を allow と ignore を使ってカスタマイズできます。 Dependabotは許可されたすべての依存関係をチェックし、それから無視された依存関係やバージョンをフィルタリングします。 そのため、allow と ignore の両方で一致する依存関係は無視されます。

依存関係は、ignore にそれを追加するか、Dependabot によって開かれる pull request で @dependabot ignore コマンドを使うことによって、無視できます。

@dependabot ignore から ignore 条件を作成する

@dependabot ignore コマンドを使って無視された依存関係は、各パッケージ マネージャーに集中的に保存されます。 dependabot.yml ファイルで依存関係の無視を始めると、これらの既存の設定が、構成での ignore の依存関係とともに考慮されます。

リポジトリで "@dependabot ignore" in:comments を検索する、または @dependabot show DEPENDENCY_NAME ignore conditions のコメント コマンドを使用することで、リポジトリに ignore のユーザー設定が保存されているかどうかを確認できます。 この方法で無視された依存関係の更新を解除したいなら、pull request を再度開いてください。 これにより、pull request を終了したときに設定された ignore 条件がクリアされ、依存関係の Dependabot の更新が再開されます。 依存関係を新しいバージョンに更新するには、pull request をマージします。 グループ化された を更新するための pull request では、@dependabot unignore コマンドを使用して依存関係の ignore の設定を消去することもできます。

@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 を使用して更新する依存関係をカスタマイズする方法を示します。

特定のバージョン以降の更新プログラムを無視する

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は、リポジトリ中の必要に応じて自動的にこれらのデフォルトラベルを作成します。

既定のラベルをオーバーライドし、パッケージ マネージャーに対して発行されるすべての pull request に代替のラベルを指定するには、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

パッケージ マネージャーに対して発行されたすべての pull request をマイルストーンと関連付けるには、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 つの pull request をオープンします。 Dependabot からの未解決の pull request が 5 つあると、Dependabot は、未解決の要求の一部がマージまたは閉じられるまで、新しい要求を開けません。 この制限を変更するには open-pull-requests-limit を使います。 これは、パッケージマネージャーのバージョン更新を一時的に無効にする簡単な方法としても使用できます。

このオプションはセキュリティアップデートに影響を与えません。セキュリティアップデートには、10 件のオープン pull request の内部制限があります。

# 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 は、pull request ごとにブランチを生成します。 各ブランチ名には、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はオープンな pull request への変更を検出すると、その pull request を自動的にリベースします。 この動作を無効にするには、rebase-strategy を使います。

利用可能なリベース戦略

• 既定の動作を使い、変更が検出されたときに開かれている pull request をリベースするには auto。
• 自動リベースを無効にするには disabled。

rebase-strategy が auto に設定されている場合、Dependabot では次の場合に pull request のリベースを試みます。

• Dependabot version updates を使用する場合 (スケジュールの実行時に開いている Dependabot pull request に対して)。
• 閉じた Dependabot pull request をもう一度開く場合。
• Dependabot 構成ファイルの target-branch の値を変更する場合。 このフィールドについて詳しくは、「target-branch」を参照してください。
• Dependabot により、ターゲット ブランチへの最近のプッシュ後に Dependabot pull request が競合していることが検出された場合。

rebase-strategy が disabled に設定されている場合、Dependabot では pull request のリベースを停止します。

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

パッケージ マネージャーに対して発行されたすべての pull request に個々のレビュー担当者またはレビュー担当者のチームを指定するには、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 を使います。

サポート状況の値

• monday
• tuesday
• wednesday
• thursday
• friday
• saturday
• sunday

# 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 はデフォルトのブランチでマニフェストファイルをチェックし、このブランチに対するバージョン更新の pull request を発行します。 マニフェスト ファイルと pull request に別のブランチを指定するには、target-branch を使います。 このオプションを使用すると、このパッケージマネージャーの設定は、セキュリティアップデートのために発行された pull request に影響しなくなります。

# 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	ロックファイルを更新する pull request のみを作成します。 パッケージマニフェストの変更が必要になる新しいバージョンは無視します。
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	該当なし	該当なし

# 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

バージョン管理タグ

• アルファ、ベータ、安定バージョンなど、ソフトウェア リリース ライフサイクルのステージを表します。
• 発行者は、パッケージをいっそう効率的に配布できます。
• バージョンの安定性を示し、機能と安定性に関してユーザーが予期する必要があることを伝えます。

Dependabot は、異なるエコシステムで、プレリリース、安定バージョン、カスタムのタグのさまざまなバージョン管理タグを認識します。

dependabot.yml ファイルでは使用できるバージョン管理タグは制御されませんが、サポートされているバージョン管理タグのうち更新を無視するものを、ignore などの構成オプションで定義できます。

サポートされているバージョン管理タグ

パッケージ マネージャー	YAML の値	サポートされるタグ	使用例
Maven	maven	alpha, a, beta, b, milestone, m, rc, cr, sp, ga, final, release, snapshot	spring-security-web@5.6.0-SNAPSHOT, spring-core@5.2.0.RELEASE
npm	npm	alpha、beta、canary、dev、experimental、latest、legacy、next、nightly、rc、release、stable	lodash@beta、react@latest、express@next
pnpm	npm	alpha、beta、canary、dev、experimental、latest、legacy、next、nightly、rc、release、stable	lodash@1.2.0-alpha、react@alpha、vue@next
yarn	npm	alpha、beta、canary、dev、experimental、latest、legacy、next、nightly、rc、release、stable	lodash@1.2.0-alpha、axios@latest、moment@nightly

バージョン管理タグ用語集

• alpha: 初期バージョン。不安定であり、不完全な機能がある可能性があります。
• beta: アルファより安定していますが、バグが残っている可能性があります。
• canary: テストのために定期的に更新されるプレリリース バージョン。
• dev: 開発バージョンを表します。
• experimental: 試験的な機能を備えたバージョン。
• latest: 最新の安定したリリース。
• legacy: 古い、または非推奨のバージョン。
• next: 次回のリリース バージョン。
• nightly: 夜間にビルドされるバージョン。多くの場合、最新の変更が含まれます。
• rc: 安定リリースに近いリリース候補。
• release: 公式のリリース バージョン。
• stable: 最も信頼性が高く、運用に対応したバージョン。

プライベートレジストリの構成オプション

最上位の registries キーは省略可能です。 このキーでは、Dependabot がプライベートパッケージレジストリにアクセスするために使用する認証の詳細を指定できます。

git の type を指定することで、GitLab または Bitbucket によってホストされるプライベート パッケージ レジストリに Dependabot アクセス権を付与できます。 詳細については、gitを参照してください。

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 のプライベート レジストリの構成に関するガイダンス」を参照してください。

cargo-registry

cargo-registry タイプは、トークンをサポートします。

このレジストリの種類は、url オプションで指定されたパスのプレフィックスと一致します。 つまり、同じホストに複数の資格情報を指定でき、これを使用して異なるパスにアクセスできます。 ただし、同じホストに複数のレジストリがない場合は、レジストリへのすべてのパスが資格情報を受け取るように、url からパスを省略することをお勧めします。

registries:
  cargo-example:
    type: cargo-registry
    registry: "name-of-your-registry"
    url: https://cargo.cloudsmith.io/foobaruser/test/
    token: "Token ${{secrets.CARGO_TOKEN}}"

https://cargo.cloudsmith.io プライベート レジストリに対してこの構成をテストしました。

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 の構成ファイルで参照されるパスワードは、元の (エンコードされていない) パスワードである必要があります。

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}}

pub-repository

pub-repository タイプは、URL とトークンをサポートします。

registries:
  my-pub-registry:
    type: pub-repository
    url: https://example-private-pub-repo.dev/optional-path
    token: ${{secrets.MY_PUB_TOKEN}}
updates:
  - package-ecosystem: "pub"
    directory: "/"
    schedule:
      interval: "weekly"
    registries:
      - my-pub-registry

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 ベータ ecosystem

version: 2
enable-beta-ecosystems: true
updates:
  - package-ecosystem: "beta-ecosystem"
    directory: "/"
    schedule:
      interval: "weekly"