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

`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` ファイルの構成オプション

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

オプション	必須	セキュリティ更新プログラム	バージョンアップデート	説明
`package-ecosystem`				使用するパッケージマネージャー
`directory`				パッケージマニフェストの場所
`schedule.interval`				更新を確認する頻度
`allow`				許可する更新をカスタマイズする
`assignees`				プルリクエストのアサイン担当者
`commit-message`				コミットメッセージの環境設定
`enable-beta-ecosystems`				ベータレベルのサポートを備えたエコシステムを有効にする
`groups`				特定の依存関係のグループ更新
`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、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 の最大数を変更します。

注: これらの構成オプションの一部は、脆弱性のあるパッケージマニフェストのセキュリティ更新のために送信される pull request にも影響を与える可能性があります。

脆弱性のあるパッケージマニフェストのセキュリティアップデートは、デフォルトブランチでのみ発生します。構成オプションが同じブランチに設定されていて (target-branch を使っていないかぎり該当します)、脆弱性のあるマニフェストの package-ecosystem と directory を指定している場合、セキュリティ更新の pull request で関連オプションが使われます。

一般に、セキュリティアップデートでは、メタデータの追加や動作の変更など、プルリクエストに影響する設定オプションが使用されます。セキュリティ更新プログラムについて詳しくは、「Configuring Dependabot security updates (Dependabot セキュリティアップデートの構成)」をご覧ください。

`package-ecosystem`

[必須] 。 Dependabot で新しいバージョンを監視するパッケージマネージャーごとに、1 つの package-ecosystem 要素を追加します。リポジトリには、これらの各パッケージマネージャーの依存関係マニフェストまたはロックファイルも含まれている必要があります。サポートするパッケージマネージャーに対してベンダリングを有効にする場合、ベンダリングされた依存関係が必須ディレクトリに存在する必要があります。詳しくは、「vendor」をご覧ください。

以下の表は、各パッケージマネージャについて以下の項目を示しています。

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
pnpm	`npm`	v7, v8
poetry	`pip`	v1
pub	`pub`	v2
Swift	`swift`	v5	(git only)
Terraform	`terraform`	>= 0.13, <= 1.5.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」を参照してください。

GitHub Actions

Dependabot は、actions/checkout@v4 などの GitHub リポジトリ構文を使って、GitHub Actions に対する更新のみをサポートします。 Docker Hub と GitHub Packages Container registry URL は現在、サポートされていません。

Dependabot では、GitHub Actions のパブリックリポジトリとプライベートリポジトリの両方がサポートされます。プライベートレジストリの構成オプションについては、「dependabot.yml ファイルの構成オプション」の「git」を参照してください。

Gradle

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

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

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

注: Dependency Submission API を使用して Gradle 依存関係を依存関係グラフにアップロードすると、依存関係ファイルで明示的に言及されていない間接的な依存関係であっても、すべてのプロジェクトの依存関係がアップロードされます。間接的な依存関係でアラートが検出されると、Dependabot はリポジトリ内の脆弱な依存関係を見つけることができないため、そのアラートのセキュリティ更新プログラムを作成しません。

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 の更新を実行しません。

Swift

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

yarn

Dependabot では、v2 以降のベンダー依存関係がサポートされています。

3 つのパッケージマネージャーの基本的なセットアップの例

# Basic set up for three package managers

version: 2
updates:

  # Maintain dependencies for GitHub Actions
  - package-ecosystem: "github-actions"
    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 でワークフローファイルを確認します。

# 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`
    directory: "/"
    schedule:
      interval: "weekly"

`schedule.interval`

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

注: schedule.time オプションはベストエフォート (できる限り努力する) であり、依存関係のバージョンを新しいものに更新するための pull request を Dependabot で開始するまで多少の時間がかかることがあります。

間隔の型	頻度
`daily`	月曜日から金曜日までのすべての平日に実行します。
`weekly`	毎週 1 回実行します。デフォルトでは月曜日に設定されています。これを変更するには、`schedule.day` を使います。
`monthly`	毎月 1 回実行します。その月の最初の日に設定されています。

# Set update schedule for each package manager

version: 2
updates:

  - package-ecosystem: "github-actions"
    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 のセキュリティアップデート」を参照してください。

構成ミスやバージョンに互換性がないために Dependabot の実行に失敗したと表示されることがあります。実行に 30 回失敗すると、依存関係グラフからの更新を手動でトリガーするか、マニフェストファイルを更新するまで、Dependabot version updates はその後のスケジュールされた実行をスキップします。 Dependabot security updates は、通常どおり、引き続き実行されます。

`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`	[Development dependency group] 内の依存関係のみ。

# 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 オプションを使って、環境設定を明示的に指定します。

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

注: prefix と prefix-development オプションには、50 文字制限があります。

prefix では、すべてのコミットメッセージのプレフィックスを指定します。コミットメッセージのプレフィックスを指定すると、定義されたプレフィックスが文字、数字、終わりかっこ、または右角かっこで終われば、GitHub によって、定義されたプレフィックスとコミットメッセージの間にコロンを自動的に追加されます。つまり、たとえば、プレフィックスを空白で終えた場合、プレフィックスとコミットメッセージの間にコロンは追加されません。次のコードスニペットでは、同じ構成ファイル内の両方の例を示します。
prefix-development では、Development 依存関係グループ内の依存関係を更新するすべてのコミットメッセージに個別のプレフィックスを指定します。このオプションの値を指定すると、prefix は、Production 依存関係グループの依存関係の更新にのみ使われます。これは、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

`groups`

Dependabot version updates のグループのみを作成できます。 Dependabot security updates ではグループ化された更新はサポートされていません。

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

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

注: SemVer は、x.y.z の形式でソフトウェアパッケージのバージョンを定義するための標準として認められています。 Dependabot では、この形式のバージョンは常に major.minor.patch.

グループを初めて構成するときに、pull request のタイトルとブランチ名に表示されるグループ名を指定します。その後、グループに特定の依存関係を含めたりグループから除外したりするその他のオプションを定義できます。グループを定義する場合 patterns、dependency-type、または update-types のオプション、またはそれらの任意の組み合わせを使用する必要があります。

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

# `dependabot.yml` file using the `dependency-type` option to group updates
# in conjunction with `patterns` and `exclude-patterns`.

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

# `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.
version: 2
updates:
  # Keep bundler dependencies up to date
  - package-ecosystem: "bundler"
    directory: "/"
    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)
          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-*"

# `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.
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      angular:
        patterns:
        - "@angular*"
        update-types:
        - "minor"
        - "patch"

# `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
groups:
  angular:
    patterns:
    - "@angular*"
    update-types:
    - "minor"
    - "patch"
ignore:
  - dependency-name: "@angular*"
    update-types: ["version-update:semver-major"]

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を管理する」を参照してください。

`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"]

注: 構成ファイルの ignore オプションにアクセスできない依存関係を追加した場合でも、Dependabot は、ファイル内のすべての依存関係にアクセスできる場合は、マニフェストまたはロックファイルでのバージョン更新のみを実行できます。詳細については、「Organization のセキュリティおよび分析設定を管理する」および「Dependabot エラーのトラブルシューティング」を参照してください。

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

`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 つのプルリクエストをオープンします。 Dependabot からの未解決の pull request が 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はオープンなPull Requestへの変更を検出すると、そのPull Requestを自動的にリベースします。この動作を無効にするには、rebase-strategy を使います。

注: pull request が 30 日間マージされていない場合、Dependabot は pull request のリベースを停止します。 pull request の手動でのリベースとマージは引き続きできます。

利用可能なリベース戦略

既定の動作を使い、変更が検出されたときに開かれている 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 のリベースを停止します。

注: この動作は、ターゲットブランチと競合する pull request にのみ適用されます。 Dependabot では、rebase-strategy の設定が変更される前に開かれた pull request と (開かれてから 30 日まで)、スケジュールされた実行の一部である 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 の設定を含める必要があります。 registries を "*" に設定することで、定義されたすべてのリポジトリを使用できるようにすることができます。また、更新が使用できるレジストリをリストすることもできます。これを行うには、dependabot.yml ファイルの最上位の registries セクションで定義されているレジストリの名前を使います。詳しくは、以下の「プライベートレジストリの設定オプション」をご覧ください。

使用可能なオプションの詳細と、プライベートレジストリを構成するときの推奨事項とアドバイスについては、「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 している場合と同様に、Organization を含む完全なチーム名を使う必要があります。

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 に別のブランチを指定するには、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 の使用方法の例を示します。

現在の制約	現在のバージョン	新しいバージョン	戦略	New の制約
^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/ で pull request をお送りください。

# 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 がプライベートパッケージレジストリにアクセスするために使用する認証の詳細を指定できます。

注: プライベートネットワーク上のファイアーウォールの内側のプライベートレジストリはサポートされていません。

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`	レジストリのタイプを指定します。タイプの一覧については下記をご覧ください。
`url`	このレジストリの依存関係にアクセスするために使用する URL。プロトコルはオプションです。指定しないと、`https://` が想定されます。 Dependabot が必要に応じて末尾のスラッシュを追加または無視します。
`username`	Dependabot がレジストリにアクセスするために使用するユーザ名。 `username` は、アカウントのユーザー名またはメールアドレスです。
`password`	指定したユーザのパスワードを含む Dependabot シークレットへのリファレンス。詳しくは、「Dependabot のプライベートレジストリへのアクセスの構成」を参照してください。 `password` はユーザー名が指定したアカウントのパスワードです。 If the account is a GitHub account, you can use a GitHub personal access token in place of the password.
`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 タイプは、ユーザー名とパスワードをサポートします。 If the account is a GitHub account, you can use a GitHub personal access token in place of the password.

このレジストリの種類は、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 ドキュメントのトークン認証仕様と Wikipedia の基本アクセス認証に関するページを参照してください。

docker-registry タイプは、ユーザー名とパスワードをサポートします。 If the account is a GitHub account, you can use a GitHub personal access token in place of the password.

このレジストリの種類は、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 資格情報を使ってプライベート Amazon 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 タイプは、ユーザー名とパスワードをサポートします。 If the account is a GitHub account, you can use a GitHub personal access token in place of the password.

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 タイプは、ユーザー名とパスワードをサポートします。 If the account is a GitHub account, you can use a GitHub personal access token in place of the password.

このレジストリの種類は、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 タイプは、ユーザー名とパスワード、またはトークンをサポートします。 If the account is a GitHub account, you can use a GitHub personal access token in place of the password.

ユーザー名とパスワードを使うとき、.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 タイプは、ユーザー名とパスワード、またはトークンをサポートします。 If the account is a GitHub account, you can use a GitHub personal access token in place of the password.

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 タイプは、ユーザー名とパスワード、またはトークンをサポートします。 If the account is a GitHub account, you can use a GitHub personal access token in place of the password.

このレジストリの種類は、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 タイプは、ユーザー名とパスワード、またはトークンをサポートします。 If the account is a GitHub account, you can use a GitHub personal access token in place of the password.

このレジストリの種類は、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"

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

この記事の内容