Dependabot オプションリファレンス

`dependabot.yml` ファイルについて

dependabot.yml ファイルで、Dependabot がバージョン更新プログラムを使って依存関係を保持する方法を定義します。さらに、アイコンが表示されているいずれのオプションを使っても、Dependabot がセキュリティ更新プログラムに対する pull request の作成方法を変更できます。ただし、target-branch が使われている場合は除きます。

Dependabot の構成ファイルである dependabot.yml では、YAML 構文を使います。 YAML を初めて使う場合、詳細については、「Learn YAML in five minutes」(5 分で学ぶ YAML) を参照してください。

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

Note

Dependabot alerts は、dependabot.yml ファイルではなく、リポジトリまたは organization の [Settings] タブで構成されます。「Dependabot アラートの構成」を参照してください。

必須のキー

キー	Location	パーパス
`version`	最上位レベル	使う Dependabot 構成構文。常に `2` です。
`updates`	最上位レベル	更新する各 `package-ecosystem` を定義するセクション。
`package-ecosystem`	`updates` の下	更新するパッケージマネージャーを定義します。
`directory`	各 `package-ecosystem` エントリの下	更新するマニフェストまたはその他の定義ファイルの場所を定義します。
`schedule.interval`	各 `package-ecosystem` エントリの下	バージョン更新プログラムを検索するかどうかを定義します (`daily`、`weekly`、または `monthly`)。

必要に応じて、最上位レベルの registries キーを含めて、プライベートレジストリのアクセス詳細を定義することもできます。「最上位レベルの registries キー」を参照してください。

YAML

# Basic `dependabot.yml` file with
# minimum configuration for two package managers

version: 2
updates:
  # Enable version updates for npm
  - package-ecosystem: "npm"
    # Look for `package.json` and `lock` files in the `root` directory
    directory: "/"
    # Check the npm registry for updates every day (weekdays)
    schedule:
      interval: "daily"

  # Enable version updates for Docker
  - package-ecosystem: "docker"
    # Look for a `Dockerfile` in the `root` directory
    directory: "/"
    # Check for updates once a week
    schedule:
      interval: "weekly"


# Basic `dependabot.yml` file with
# minimum configuration for two package managers

version: 2
updates:
  # Enable version updates for npm
  - package-ecosystem: "npm"
    # Look for `package.json` and `lock` files in the `root` directory
    directory: "/"
    # Check the npm registry for updates every day (weekdays)
    schedule:
      interval: "daily"

  # Enable version updates for Docker
  - package-ecosystem: "docker"
    # Look for a `Dockerfile` in the `root` directory
    directory: "/"
    # Check for updates once a week
    schedule:
      interval: "weekly"

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

`allow`

パッケージエコシステムに対してどの依存関係を保持するかを正確に定義するために使います。多くの場合、ignore オプションと共に使われます。例については、「Dependabot で更新する依存関係を制御する」を参照してください。

Dependabot の既定の動作:

マニフェストで明示的に定義されたすべての依存関係は、バージョン更新プログラムによって最新の状態に保たれます。
脆弱な依存関係があるロックファイルに定義されているすべての依存関係は、セキュリティ更新プログラムによって更新されます。

allow を指定した場合、Dependabot によって次のプロセスが使われます。

明示的に許可した依存関係をすべてチェックします。
次に、無視された依存関係またはバージョンを除外します。

依存関係が allow と ignore ステートメントと一致する場合、依存関係は無視されます。

パラメーター	パーパス
`dependency-name`	名前が一致する依存関係の更新を許可します。必要に応じて、`*` を使って 0 個以上の文字と一致させることができます。
`dependency-type`	特定の種類の依存関係の更新を許可します。

`dependency-name` (`allow`)

ほとんどのパッケージマネージャーでは、ロックまたはマニフェストファイルで指定された依存関係名と一致する値を定義する必要があります。一部のシステムには、より複雑な要件があります。

パッケージマネージャー	必須の形式	例
Gradle と Maven	`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` (`allow`)

依存関係の種類	パッケージマネージャーによるサポート	更新の許可
`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` (すべてのマネージャーではない)	パッケージマネージャーによって開発依存関係として定義された依存関係のみ。

`assignees`

パッケージエコシステムに対して生成されたすべての pull request に個別の担当者を指定します。例については、「実際のプロセスに合わせて Dependabot pull request をカスタマイズする」を参照してください。

Dependabot の既定の動作:

Pull request は担当者なしで作成されます。

assignees が定義されている場合:

バージョン更新プログラムのすべての pull request は、選んだ担当者を使って作成されます。
target-branch で既定ではないブランチに対する更新プログラムを定義していない場合、セキュリティ更新プログラムのすべての pull request は、選んだ担当者を使って作成されます。

担当者はリポジトリへの書き込みアクセス権限を持っている必要があります。 Organization が所有するリポジトリの場合、読み取りアクセス権を持つ organization メンバーも有効な担当者です。

`commit-message`

コミットメッセージの形式を定義します。 Pull request のタイトルはコミットメッセージに基づいて記述されるため、この設定は pull request のタイトルにも影響します。例については、「実際のプロセスに合わせて Dependabot pull request をカスタマイズする」を参照してください。

Dependabot の既定の動作:

コミットメッセージは、リポジトリで検出されたものと同様のパターンに従います。

commit-message が定義されている場合:

すべてのコミットメッセージは、定義されたパターンに従います。
target-branch で既定ではないブランチに対する更新プログラムを定義していない場合、すべてのコミットメッセージは定義されたパターンに従います。

パラメーター	パーパス
`prefix`	すべてのコミットメッセージと pull request のタイトルのプレフィックスを定義します。
`prefix-development`	サポートされているシステム上で、Development 依存関係グループ内の依存関係を更新するコミットに使う別のプレフィックスを定義します。
`include`	コミットメッセージのプレフィックスの後にその他の情報を入力します。

Tip

グループ化された更新プログラムに対して pull request が生成されると、ブランチ名と pull request のタイトルはグループ IDENTIFIER によって定義されます。「groups」を参照してください。

`prefix`

prefix-development も定義されていない場合、すべてのコミットメッセージに使われます。
値は最長 50 文字です。
値の末尾が文字、数字、終わり丸かっこ、または終わり角かっこである場合、メインのコミットメッセージを追加する前に、Dependabot によってプレフィックスの後にコロンが挿入されます。
コロンの追加を停止するには、値の末尾を空白文字にします。

`prefix-development`

サポートしているもの: bundler、composer、mix、maven、npm、pip。

Development 依存関係グループ内の依存関係を更新するコミットメッセージにのみ使われます。
それ以外の場合、パラメーターは prefix パラメーターとまったく同じように動作します。

`include`

値 scope のみをサポートします
定義すると、プレフィックスの後にコミットで更新される依存関係の種類 (deps または deps-dev) が続きます。

`directory`

必須のオプション。各パッケージマネージャー (package.json や Gemfile など) のパッケージマニフェストの場所を定義するために使用します。この情報がないと、Dependabot ではバージョン更新プログラムの pull request を作成できません。例については、「dependabot.yml ファイルの例」を参照してください。

ほとんどのパッケージマネージャーのリポジトリのルートに対して相対的なディレクトリを定義します。
GitHub Actions には、値 / を使います。 Dependabot は、/.github/workflows ディレクトリとルートディレクトリの action.yml/action.yaml ファイルを検索します。

構成ファイル内で複数のブロックを使ってエコシステムの 1 つのターゲットブランチの更新を定義する必要がある場合は、すべての値が一意であり、定義したディレクトリに重複がないことを確認する必要があります。

`groups`

パッケージマネージャーによって管理される 1 つ以上の依存関係のセットを作成し、更新プログラムを少数の対象を絞った pull request にグループ化するようにルールを定義します。例については、「Dependabot バージョン更新プログラムに合わせて pull request の作成を最適化する」を参照してください。

Dependabot の既定の動作:

バージョン更新プログラムのために、新しいバージョンに更新する必要がある依存関係ごとに 1 つの pull request を開きます。

groups を使ってルールを定義する場合:

1 つのルールと一致する依存関係のすべてのバージョン更新プログラムは、1 つの pull request に結合されます。
依存関係が複数のルールと一致する場合、その依存関係は最初に一致したグループに含まれます。
一致するルールがない古い依存関係は、個別の pull request で更新されます。

パラメーター	パーパス
`IDENTIFIER`	ブランチ名と pull request のタイトルで使うグループの識別子を定義します。この先頭と末尾は文字にする必要があります。また、文字、パイプ `\|`、アンダースコア `_`、またはハイフン `-` を含めることができます。
`dependency-type`	グループを 1 つの種類に制限します。サポートされる値: `development` または `production`。
`patterns`	名前が一致する依存関係を含めるパターンを 1 つ以上定義します。
`exclude-patterns`	グループから依存関係を除外するパターンを 1 つ以上定義します。
`update-types`	グループを 1 つ以上のセマンティックバージョニングレベルに制限します。サポートされる値: `minor`、`patch`、`major`。

`dependency-type` (`groups`)

サポートしているもの: bundler、composer、mix、maven、npm、pip。

既定では、グループにはすべての種類の依存関係が含まれます。

"Development 依存関係グループ" に依存関係のみを含めるには、development を使います。
"Production 依存関係グループ" に依存関係のみを含めるには、production を使います。

`patterns` と `exclude-patterns` (`groups`)

どちらのオプションも、依存関係名との一致を定義する際にワイルドカードとして * を使用できます。依存関係がパターンと除外パターンの両方と一致する場合は、グループから除外されます。

`update-types` (`groups`)

既定では、グループにはすべてのセマンティックバージョン (SemVer) 更新プログラムが含まれます。 SemVer は、x.y.z の形式でソフトウェアパッケージのバージョンを定義するための標準として認められています。 Dependabot は、この形式のバージョンが常に major.minor.patch であると想定します。

パッチリリースを含めるには、patch を使います。
マイナーリリースを含めるには、minor を使います。
メジャーリリースを含めるには、major を使います。

例については、「Dependabot で更新する依存関係を制御する」を参照してください。

`ignore`

パッケージエコシステムに対してどの依存関係を保持するかを正確に定義するには、allow オプションと共に使います。 Dependabotは許可されたすべての依存関係をチェックし、それから無視された依存関係やバージョンをフィルタリングします。そのため、許可と無視の両方と一致する依存関係は無視されます。例については、「Dependabot で更新する依存関係を制御する」を参照してください。

Dependabot の既定の動作:

マニフェストで明示的に定義されたすべての依存関係は、バージョン更新プログラムによって最新の状態に保たれます。
脆弱な依存関係があるロックファイルに定義されているすべての依存関係は、セキュリティ更新プログラムによって更新されます。

ignore を使うと、Dependabot によって次のプロセスが使われます。

明示的に許可した依存関係をすべてチェックします。
次に、無視された依存関係またはバージョンを除外します。

依存関係が allow と ignore ステートメントと一致する場合、依存関係は無視されます。

パラメーター	パーパス
`dependency-name`	名前が一致する依存関係の更新を無視します。必要に応じて、`*` を使って 0 個以上の文字と一致させることができます。
`versions`	特定のバージョンまたはバージョンの範囲を無視します。
`update-types`	1 つ以上のセマンティックバージョニングレベルへの更新プログラムを無視します。サポートされる値: `version-update:semver-minor`、`version-update:semver-patch`、`version-update:semver-major`。

`dependency-name` (`ignore`)

パッケージマネージャー	必須の形式	例
Gradle と Maven	`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` を使います。

`versions` (`ignore`)

特定のバージョンまたはバージョン範囲を無視するために使います。範囲を定義する場合は、パッケージマネージャーの標準パターンを使います。次に例を示します。

npm: ^1.0.0 を使います
Bundler: ~> 2.0 を使います
Docker: Ruby バージョン構文を使います
NuGet: 7.* を使います

例については、「Dependabot で更新する依存関係を制御する」を参照してください。

`update-types` (`ignore`)

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

パッチリリースを含めるには、patch を使います。
マイナーリリースを含めるには、minor を使います。
メジャーリリースを含めるには、major を使います。

`insecure-external-code-execution`

サポート: bundler、mix、および pip。

更新時に、Dependabot がマニフェスト内の外部コードを実行できるようにします。例については、「外部コードの実行を許可する」を参照してください。

Dependabot の既定の動作:

Dependabot に 1 つ以上のレジストリへのアクセスを許可すると、侵害されたパッケージからコードを保護するために、外部コードの実行は自動的に無効になります。
コードを実行できないと、バージョン更新プログラムが失敗する場合があります。

insecure-external-code-execution を許可する場合:

Dependabot により、バージョン更新プログラムプロセスの一部としてマニフェスト内のコードが実行されます。
コードは、その updates の設定に関連付けられたレジストリ内のパッケージマネージャーにのみアクセスできます。最上位の registries 構成で定義されているレジストリへのアクセスは許可されません。
そのため、更新プログラムは成功するはずですが、侵害されたパッケージが資格情報を盗んだり、構成済みのレジストリにアクセスしたりする可能性もあります。

サポートされる値: allow。

`labels`

パッケージマネージャーに対して発行されるすべての pull request に独自のラベルを指定します。例については、「実際のプロセスに合わせて Dependabot pull request をカスタマイズする」を参照してください。

Dependabot の既定の動作:

すべての pull request には dependencies ラベルが付いています。
複数のパッケージマネージャーを定義すると、エコシステムまたは言語の追加ラベルが各 pull request に追加されます。例: Gradle の更新プログラムの場合は java、git サブモジュールの更新プログラムの場合は submodules です。
Dependabotは、リポジトリ中の必要に応じて自動的にこれらのデフォルトラベルを作成します。

labels が定義されている場合:

指定したラベルは、既定のラベルの代わりに使われます。
これらのラベルのいずれかがリポジトリで定義されていない場合は無視されます。
labels: [ ] を使うと、既定のラベルを含むすべてのラベルを無効にできます。

target-branch を使って既定以外のブランチのバージョンアップデートをチェックしないかぎり、このオプションの設定も、このパッケージマネージャーのマニフェストファイルに対するセキュリティ更新プログラムの pull request に影響します。

`milestone`

パッケージマネージャーに対して生成されたすべての pull request をマイルストーンに関連付けます。例については、「実際のプロセスに合わせて Dependabot pull request をカスタマイズする」を参照してください。

Dependabot の既定の動作:

マイルストーンは使われません。

milestone が定義されている場合:

パッケージマネージャーに対するすべての pull request がマイルストーンに追加されます。

サポートされる値: マイルストーンの数値識別子。

Tip

マイルストーンを表示した場合、ページURL の milestone より後の最後の部分が識別子になります。例: https://github.com/<org>/<repo>/milestone/3。「マイルストーンの進捗状況を表示する」を参照してください。

`open-pull-requests-limit`

開いているバージョン更新プログラムの pull request の最大数に関する制限はいつでも変更できます。

Dependabot の既定の動作:

バージョン更新プログラムを含む pull request が 5 つ開いている場合、それらの開いている request の一部がマージまたは終了されるまで、それ以上の pull request は生成されません。
セキュリティ更新プログラムには、開いている pull request は 10 件という別の内部制限があり、変更できません。

open-pull-requests-limit が定義されている場合:

Dependabot により、定義した整数値までの pull request が開かれます。
このオプションを 0 に設定すると、パッケージマネージャーのバージョン更新プログラムを一時的に無効にできます。「Dependabot version updates を無効にする」を参照してください。

`package-ecosystem`

必須のオプション。 Dependabot で新しいバージョンを監視するパッケージマネージャーごとに、package-ecosystem 要素を 1 つ定義します。リポジトリには、各パッケージマネージャーの依存関係マニフェストまたはロックファイルも含める必要があります。「dependabot.yml ファイルの例」を参照してください。

パッケージマネージャー	YAML値	サポートされているバージョン
Bundler	`bundler`	v1, v2
Cargo	`cargo`	v1
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`	6.7.0 以下
pip	`pip`	v21.1.2
pip-compile	`pip`	6.1.0
pipenv	`pip`	<= 2021-05-29
pnpm	`npm`	v7, v8 v9 (バージョン更新プログラムのみ)
poetry	`pip`	v1
pub	`pub`	v2
Swift	`swift`	v5
Terraform	`terraform`	>= 0.13, <= 1.8.x
yarn	`npm`	v1、v2、v3

`pull-request-branch-name.separator`

ブランチ名の生成時に使う区切り記号を指定します。例については、「実際のプロセスに合わせて Dependabot pull request をカスタマイズする」を参照してください。

Dependabot の既定の動作:

次の形式のブランチ名を生成します: dependabot/PACKAGE_MANAGER/DEPENDENCY

pull-request-branch-name.separator が定義されている場合:

/ ではなく指定した文字を使います。

サポートされる値: "-"、_、/

Tip

ハイフン記号は、空の YAML リストの開始として解釈されないようにエスケープする必要があります。

`rebase-strategy`

Dependabot によって生成された pull request の自動リベースを無効にします。

Dependabot の既定の動作は、Dependabot がバージョンまたはセキュリティ更新プログラムの pull request に対する変更を検出したときに、開いている pull request をリベースすることです。次の場合、Dependabot によって変更がチェックされます。

バージョン更新プログラムをチェックするスケジュールが実行される。
終了した Dependabot pull request を再度開く。
Dependabot 構成ファイル内の target-branch の値を変更する (「target-branch」を参照してください)。
ターゲットブランチへの最近のプッシュ後に、Dependabot pull request に競合が発生した。

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

Note

リベースを無効にする前に開かれていた pull request は、開かれてから 30 日後までリベースされ続けます。これは、ターゲットブランチと競合するすべての pull request と、バージョン更新プログラムのすべての pull request に影響します。

`registries`

Dependabot がより広範囲の依存関係を更新できるように、プライベートパッケージレジストリへのアクセスを構成します。「Dependabot のプライベートレジストリへのアクセスの構成」と「Dependabot のプライベートレジストリの構成に関するガイダンス」を参照してください。

dependabot.yml ファイルには、registries キーを使用できる場所が 2 つあります。

最上位レベルには、使うプライベートレジストリとそのアクセス情報を定義します。「Dependabot のプライベートレジストリへのアクセスの構成」を参照してください。
updates ブロック内で、各パッケージマネージャーが使うプライベートレジストリを指定できます。

Dependabot の既定の動作では、パブリックにアクセスできるレジストリに格納されている依存関係を更新する場合にのみ、pull request を生成します。

Dependabot 構成ファイルに、1 つ以上のプライベートレジストリへのアクセスを定義する最上位レベルの registries セクションがある場合、これらのプライベートレジストリの 1 つ以上を使うように各 package-ecosystem を構成できます。

registries がパッケージマネージャーに対して定義されている場合:

パッケージマネージャーに指定された各プライベートレジストリのバージョンとセキュリティの更新がチェックされます。
最上位レベルの registries セクションで定義されたアクセスの詳細が Dependabot によって使われます。

サポートされる値: REGISTRY_NAME または "*"

`reviewers`

パッケージマネージャーに対して生成されたすべての pull request に、個々のレビュー担当者またはレビュー担当者のチームを指定します。例については、「実際のプロセスに合わせて Dependabot pull request をカスタマイズする」を参照してください。

Dependabot の既定の動作:

レビュー担当者が割り当てられていない pull request が作成されます。

reviewers が定義されている場合:

バージョン更新プログラムのすべての pull request は、選んだレビュー担当者によって作成されます。
target-branch で既定ではないブランチに対する更新プログラムを定義していない場合、セキュリティ更新プログラムのすべての pull request は、選んだレビュー担当者を使って作成されます。

レビュー担当者は、少なくともそのリポジトリに対する読み取りアクセス権を持っている必要があります。

必須のオプション。 interval パラメーターを使って、構成する各パッケージマネージャーの新しいバージョンをチェックする頻度を定義します。必要に応じて、日単位と週単位の間隔で、Dependabot で更新プログラムをチェックするタイミングをカスタマイズできます。例については、「Dependabot バージョン更新プログラムに合わせて pull request の作成を最適化する」を参照してください。

パラメーター	パーパス
`interval`	必須。 Dependabot の頻度を定義します。
`day`	週単位の間隔で実行する日を指定します。
`time`	実行する時刻を指定します。
`timezone`	`time` 値のタイムゾーンを指定します。

`interval`

サポートされる値: daily、weekly、または monthly

各パッケージマネージャーでスケジュール間隔を定義する必要があります。

月曜日から金曜日までの平日に実行するには、daily を使います。
週 1 回 (既定では月曜日) 実行するには、weekly を使います。
毎月 1 日に実行するには、monthly を使います。

デフォルトでは、Dependabotは設定ファイル中のすべての更新を適用する時間をランダムに割り当てます。すべての間隔に特定のランタイムを設定するには、time および timezone パラメーターを使用できます。

`day`

サポートされる値: monday、tuesday、wednesday、thursday、friday、saturday、またはsunday

必要に応じて、特定の曜日にパッケージマネージャーの更新プログラムを毎週実行します。

`time`

形式: hh:mm

必要に応じて、パッケージマネージャーのすべての更新プログラムを特定の時間に実行します。既定では、時刻は UTC として解釈されます。

`timezone`

time 値のタイムゾーンを指定します。

タイムゾーン識別子は、iana によって管理されているデータベース内のタイムゾーンと同じにする必要があります。「List of tz database time zones」(tz データベースのタイムゾーン一覧) を参照してください。

`target-branch`

バージョン更新プログラムをチェックし、バージョン更新プログラムの pull request をターゲットにするように特定のブランチを定義します。例については、「実際のプロセスに合わせて Dependabot pull request をカスタマイズする」を参照してください。

Dependabot の既定の動作:

Dependabot によって、リポジトリの既定のブランチが使われます。「既定のブランチについて」を参照してください。

target-branch が定義されている場合:

バージョン更新プログラムがチェックされるのは、ターゲットブランチ上のマニフェストファイルのみです。
バージョン更新プログラムのすべての pull request は、指定したブランチを対象として開かれます。
この package-ecosystem に対して定義されたオプションはセキュリティ更新プログラムには適用されなくなります。セキュリティ更新プログラムには、常にリポジトリの既定のブランチが使われるためです。

`vendor`

サポートしているもの: bundler と gomod のみ。

ベンダリングされた依存関係と、マニフェストファイルで定義された依存関係を保持するように Dependabot に指示します。コードをリポジトリ内に格納すると、依存関係は "ベンダリングされている" または "キャッシュされている" と記述されます。bundle cache ドキュメントと go mod vendor ドキュメントを参照してください。

例については、「Dependabot で更新する依存関係を制御する」を参照してください。

Dependabot の既定の動作:

マニフェストに記録された依存関係のみを保持し、Bundler 用として識別されたファイルをロックします。
マニフェストとロックファイルに記録されているバージョン番号を更新する、セキュリティおよびバージョン更新プログラムの pull request を生成します。
Go モジュールの場合、ベンダリングされた依存関係はすべて、vendor が有効になっているかのように自動的に特定され、保持されます。

vendor が有効な場合:

Dependabot により、リポジトリの _vendor/cache_ ディレクトリに格納されている Bundler の依存関係も保持されます。
Pull request には、リポジトリに格納されている依存関係の更新が含まれる場合があります。

サポートされる値: true または false

`versioning-strategy`

サポートしているもの: bundler、cargo、composer、mix、npm、pip、pub

Dependabot でマニフェストファイルを編集する方法を定義します。例については、「Dependabot で更新する依存関係を制御する」を参照してください。

Dependabot の既定の動作:

アプリとライブラリの依存関係を区別するようにしてください。
アプリの場合は、新しいバージョンに合わせて最小バージョン要件を常に引き上げてください。 increase 戦略。
ライブラリの場合は、可能であれば、新旧両方のバージョンを含むように、許可するバージョン要件を広げます。 widen 戦略。

versioning-strategy を定義した場合、その指定した戦略が Dependabot によって使われます。

値	動作
`auto`	既定の動作
`increase`	常に、新しいバージョンと一致するように、最低バージョン要件を追加します。範囲が既に存在する場合は、通常、下限を増やすだけです。
`increase-if-necessary`	元の制約で新しいバージョンが許可されている場合は制約をそのままにし、それ以外の場合は制約を引き上げます。
`lockfile-only`	ロックファイルを更新する pull request のみを作成します。パッケージマニフェストの変更が必要になる新しいバージョンは無視します。
`widen`	可能であれば、許可されるバージョンの要件を広げて、新旧両方のバージョンを含めます。通常は、許可される最大バージョン要件のみが追加されます。

たとえば、現在のバージョンが 1.0.0 であり、現在の制約が ^1.0.0 の場合、複数の戦略によって次の更新が行われます。

新しいバージョン 1.2.0

increase: 新しい制約 ^1.2.0
increase-if-necessary: 新しい制約 ^1.0.0
widen: 新しい制約 ^1.0.0

新しいバージョン 2.0.0

increase: 新しい制約 ^2.0.0
increase-if-necessary: 新しい制約 ^2.0.0
widen: 新しい制約 >=1.0.0 <3.0.0

Note

使っているパッケージマネージャーが versioning-strategy パラメーターの構成をまだサポートしていない場合、または必要な値をサポートしていない場合。戦略コードはオープンソースであるため、特定のエコシステムで新しい戦略をサポートしたい場合は、いつでも https://github.com/dependabot/dependabot-core/ で pull request をお送りください。

最上位レベルの `registries` キー

Dependabot が、プライベートパッケージレジストリ (GitLab または Bitbucket でホストされているレジストリなど) にアクセスするために使用できる認証の詳細を指定します。

Note

プライベートネットワーク上のファイアウォールの内側にあるプライベートレジストリは、次のエコシステムでサポートされています。

Bundler
ドッカー
グレイドル
メイヴン
Npm
NuGet
Python
Yarn

registries キーの値は連想配列で、その各要素は、特定のレジストリを指定するキーと、そのレジストリへのアクセスに必要な設定を指定する連想配列の値により構成されます。次の dependabot.yml ファイルでは、ファイルの registries セクションで dockerhub として指定されたレジストリが構成された後、ファイルの updates セクションでそれが参照されています。

YAML

# Minimal settings to update dependencies stored 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"

# Minimal settings to update dependencies stored 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 を含める必要があります。

パラメーター	パーパス
`REGISTRY_NAME`	必須: レジストリの識別子を定義します。
`type`	必須: レジストリの種類を特定します。
認証の詳細	必須: 認証の詳細を指定するためにサポートされるパラメーターは、レジストリの種類によって異なります。
`url`	必須: このレジストリ内の依存関係にアクセスするために使う URL。プロトコルはオプションです。指定しないと、`https://` が想定されます。 Dependabot が必要に応じて末尾のスラッシュを追加または無視します。
`replaces-base`	ブール値が `true` の場合、Dependabot により、そのエコシステムのベース URL ではなく、指定した `url` を使って依存関係が解決されます。

使用可能なオプションの詳細と、プライベートレジストリを構成するときの推奨事項とアドバイスについては、「Dependabot のプライベートレジストリの構成に関するガイダンス」を参照してください。

`type` と認証の詳細

プライベートレジストリにアクセスするための認証の詳細を指定するために使われるパラメーターは、レジストリ type によって異なります。

レジストリ `type`	必須の認証パラメーター
`composer-repository`	`username` と `password`
`docker-registry`	`username` と `password`
`git`	`username` と `password`
`hex-organization`	`organization` と `key`
`hex-repository`	`repo` と `auth-key` (必要に応じて、対応する `public-key-fingerprint` と共に使用します)
`maven-repository`	`username` と `password`
`npm-registry`	`username` と `password` または `token`
`nuget-feed`	`username` および `password` または `token`
`pub-registry`	`token`
`python-index`	`username` および `password` または `token`
`rubygems-server`	`username` および `password` または `token`
`terraform-registry`	`token`

認証に使われるすべての機密データを安全に格納し、その安全な場所から参照する必要があります。「Dependabot のプライベートレジストリへのアクセスの構成」を参照してください。

Tip

アカウントが GitHub アカウントの場合は、パスワードの代わりに GitHub personal access token を使用できます。

`url` および `replaces-base`

url パラメーターを使って、レジストリにアクセスする場所を定義します。省略可能な replaces-base パラメーターが有効な場合 (true)、Dependabot により、その特定のエコシステムのベース URL ではなく、url の値を使って依存関係が解決されます。

Dependabot オプション リファレンス

この機能を使用できるユーザーについて

この記事の内容