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

この記事では、 dependabot.yml ファイルで使用できる構成オプションのリファレンス情報を提供します。 これらのオプションを使用して、 Dependabot がパッケージ エコシステムを監視し、更新プログラムをスケジュールし、プル要求を作成する方法をカスタマイズします。 dependabot.yml ファイルの概要とそのしくみについては、dependabot.yml ファイルについて を参照してください。

アイコンでマークされているすべてのオプションは、Dependabot が使用されていない限り、target-branch によるセキュリティ更新プログラムの pull request 作成方法も変更します。

必要なキー

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

# 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場合は、次のプロセスを使用します。

1. 明示的に許可した依存関係をすべてチェックします。

2. 次に、無視された依存関係またはバージョンを除外します。

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

dependency-name (allow)

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

dependency-type (allow)

update-types (allow)

update-types は バージョン 更新プログラムにのみ影響し、 _セキュリティ更新プログラム_には影響しません。

許可するセマンティック バージョン (SemVer) を指定します。

SemVer は、x.y.z の形式でソフトウェア パッケージのバージョンを定義するための標準として認められています。 Dependabot は、この形式のバージョンが常に major.minor.patchされることを前提としています。 update-types値は、1 つ以上の文字列のリストです。

• version-update:semver-patchを使用して、パッチのリリースを許可します。
• マイナー リリースを許可するには、 version-update:semver-minor を使用します。
• メジャー リリースを許可するには、 version-update:semver-major を使用します。

update-typesルールからallowを省略すると、そのルールのすべての更新の種類が許可されます。

update-typesをdependency-nameまたはdependency-typeと組み合わせて、許可される更新プログラムをさらに絞り込むことができます。 これらのオプションを組み合わせる方法の例については、 AUTOTITLE を参照してください。

assignees

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

Dependabot 既定の動作:

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

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

• バージョン更新のすべてのプル要求は、選択した担当者で作成されます。
• 既定以外のブランチへの更新を定義 target-branch 場合を除き、セキュリティ更新プログラムに対するすべてのプル要求は、選択した担当者によって作成されます。

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

commit-message

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

Dependabot 既定の動作:

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

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

• すべてのコミット メッセージは、定義されたパターンに従います。
• 既定以外の分岐に対する更新を定義 target-branch 場合を除き、すべてのコミット メッセージは定義されたパターンに従います。

prefix

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

prefix-development

サポート対象: bundler、 composer、 mix、 maven、 npm、 pip、 uv。

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

include

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

cooldown

依存関係の更新のクールダウン期間を定義し、構成可能な日数だけ更新を延期することができます。 cooldown オプションは、_バージョン_更新プログラムでのみ使用でき、_セキュリティ_更新プログラムでは使用できません。

この機能を使用すると、ユーザーは新しいバージョンの更新プログラム Dependabot 生成する頻度をカスタマイズでき、更新頻度をより詳細に制御できます。 例については、「Dependabot バージョン更新プログラムに合わせて pull request の作成を最適化する」を参照してください。

Dependabot 既定の動作:

• schedule.interval で定義したスケジュールに従って更新がチェックされます。
• すべての新しいバージョンはすぐに更新対象として検討されます。

** cooldown ** が定義されている場合：

1. Dependabot は、定義された schedule.interval 設定に従って更新プログラムをチェックします。
2. Dependabot は、クールダウン設定をチェックします。
3. 依存関係の新しいリリースがクールダウン期間内にある場合、 Dependabot はその依存関係のバージョンの更新をスキップします。
4. クールダウン期間のない依存関係、またはクールダウン期間を過ぎた依存関係は、構成した versioning-strategy 設定に従って最新バージョンに更新されます。
5. 依存関係のクールダウンが終了した後、 Dependabot は、 dependabot.ymlで定義されている標準的な更新戦略に従って依存関係の更新を再開します。

cooldown の構成

以下のオプションを使ってクールダウンの期間を指定できます。

以下の表は、SemVer をサポートするパッケージ マネージャーをまとめたものです。

semver-major-days、semver-minor-days、または semver-patch-days が定義されていない場合、クールダウンベースの更新では default-days 設定が優先されます。

* exclude リストは常に include リストよりも優先されます。 依存関係が両方のリストに指定されている場合、その依存関係はクールダウンから除外され、すぐに更新されます。

directories または directory

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

• directory を使って、マニフェストのディレクトリを 1 つ定義します。

• directories を使って、マニフェストの複数のディレクトリで構成されるリストを定義します。

• ほとんどのパッケージ マネージャーのリポジトリのルートに対して相対的なディレクトリを定義します。

• GitHub Actionsの場合は、/値を使用します。 Dependabot では、 /.github/workflows ディレクトリとルート ディレクトリから action.yml/action.yaml ファイルが検索されます。

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

enable-beta-ecosystems

現在使用できません。

groups

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

Dependabot 既定の動作:

• バージョン更新とセキュリティ更新の場合、新しいバージョンに更新する必要がある依存関係ごとに 1 つの pull request を開きます。

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

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

dependency-type (groups)

サポート： bundler、composer、mix、maven、npm、およびpip。

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

• "Development dependency group" に依存関係のみを含めるには、development を使います。
• "Production dependency group" に依存関係のみを含めるには、production を使います。

group-by (groups)

groups.<group-name>.group-byを使用して、monorepo 内Dependabot複数のディレクトリ間で更新をグループ化する方法を指定します。

• 型: 文字列
• 受け入れ可能な値:dependency-name
• 適用対象: 複数のディレクトリが指定された構成

dependency-nameに設定すると、Dependabotは、ディレクトリごとに個別のプル要求ではなく、指定されたすべてのディレクトリにわたって依存関係の更新ごとに 1 つのプル要求を作成します。

ディレクトリ間グループ化の制限事項

group-by: dependency-nameを使用する場合:

• すべてのディレクトリで同じパッケージ エコシステムを使用する必要があります (たとえば、すべての npm またはすべての bundler)
• バージョン更新のみに適用されます
• ディレクトリに依存関係に互換性のないバージョン制約がある場合、 Dependabot は個別のプル要求を作成します

group-byの使用例については、Dependabot バージョン更新プログラムに合わせて pull request の作成を最適化する を参照してください。

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は次のプロセスを使用します。

1. 明示的に許可した依存関係をすべてチェックします。

2. 次に、無視された依存関係またはバージョンを除外します。

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

dependency-name (ignore)

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

versions (ignore)

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

• npm: ^1.0.0 を使います
• Bundler: ~> 2.0 を使います
• Docker: Bundler バージョンの構文を使います
• NuGet: 7.* を使います
• Maven: [1.4,) を使用する

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

update-types (ignore)

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

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

insecure-external-code-execution

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

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

Dependabot 既定の動作:

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

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

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

サポートされる値: allow。

labels

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

Dependabot 既定の動作:

• すべての pull request には dependencies ラベルが付いています。
• 複数のパッケージ マネージャーを定義すると、エコシステムまたは言語の追加ラベルが各 pull request に追加されます。 例: Gradle の更新プログラムの場合は java、git サブモジュールの更新プログラムの場合は submodules です。
• セマンティック バージョン (SemVer) ラベルがリポジトリに存在する場合は、バージョン更新の種類 (major、 minor、または patch) を示すために自動的に適用されます。
• Dependabot は、リポジトリで必要に応じてこれらの既定のラベルを自動的に作成します。

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

• 指定したラベルは、既定のラベルの代わりに使われます。
• SemVer ラベル (リポジトリに存在する場合) は、定義されているカスタム ラベルに加えて適用されます。
• これらのラベルのいずれかがリポジトリで定義されていない場合は無視されます。
• labels: [ ] を使用すると、デフォルトのラベルを含むすべてのラベルを無効化できます。

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

milestone

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

Dependabot 既定の動作:

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

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

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

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

multi-ecosystem-groups

複数のパッケージ エコシステムにまたがるグループを定義して、サポートされているすべてのパッケージ エコシステムを更新する単一の Dependabot プル要求を取得します。 この方法は、受け取る Dependabot プル要求の数を減らし、依存関係の更新ワークフローを合理化するのに役立ちます。

Dependabot 既定の動作:

• 依存関係の更新があるパッケージ エコシステムごとに個別の pull request が作成されます。

multi-ecosystem-groups が使用された場合。

• 同じグループ内の複数のパッケージ エコシステムにまたがる更新が、1 つの pull request に結合されます。
• グループには独自のスケジュールがあり、個々のエコシステム設定を継承するか、オーバーライドすることができます。

multi-ecosystem-group

multi-ecosystem-group 構成で updates パラメーターを使って、個々のパッケージ エコシステムをマルチエコシステム グループに割り当てます。

# Basic `dependabot.yml` file defining a multi-ecosystem-group
version: 2

multi-ecosystem-groups:
  infrastructure:
    schedule:
      interval: "weekly"

updates:
  - package-ecosystem: "docker"
    directory: "/"
    patterns: ["nginx", "redis"]
    multi-ecosystem-group: "infrastructure"

  - package-ecosystem: "terraform"
    directory: "/"
    patterns: ["aws"]
    multi-ecosystem-group: "infrastructure"

# Basic `dependabot.yml` file defining a multi-ecosystem-group
version: 2

multi-ecosystem-groups:
  infrastructure:
    schedule:
      interval: "weekly"

updates:
  - package-ecosystem: "docker"
    directory: "/"
    patterns: ["nginx", "redis"]
    multi-ecosystem-group: "infrastructure"

  - package-ecosystem: "terraform"
    directory: "/"
    patterns: ["aws"]
    multi-ecosystem-group: "infrastructure"

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

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

pull-request-branch-name.separator

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

Dependabot 既定の動作:

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

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

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

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

rebase-strategy

Dependabotによって発生したプルリクエストの自動リベースを無効にします。

Dependabot 既定の動作としては、バージョンまたはセキュリティ更新のプルリクエストに変更がDependabot 検出されたときに、オープンなプルリクエストをリベースします。 Dependabot 次の場合に変更をチェックします。

• バージョン更新プログラムをチェックするスケジュールが実行される。
• 閉じた Dependabot プル要求を再度開きます。
• target-branch構成ファイルでDependabotの値を変更する場合は、target-branchを参照してください。
• ターゲット ブランチに対する最近のプッシュの後で、Dependabot の pull request に競合が発生しました。

rebase-strategyがdisabledに設定されている場合、Dependabotはプル要求の再評価を停止します。

registries

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

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

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

Dependabot 既定の動作では、パブリックにアクセス可能なレジストリに格納されている依存関係を更新するためだけにプル要求を発生させます。

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

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

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

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

schedule

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

interval

Supported values: daily、 weekly、 monthly、 quarterly、 semiannually、yearly、または cron

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

• dailyを使用して、月曜日から金曜日までのすべての平日に実行します。
• 週 1 回 (既定では月曜日) 実行するには、weekly を使います。
• 毎月 1 日に実行するには、monthly を使います。
• 各四半期 (1 月、4 月、7 月、10 月) の初日に実行するには、quarterly を使います。
• 6 か月ごと (1 月と 7 月) の初日に実行するには、semiannually を使います。
• 1 月 1 日に実行するには、yearly を使います。
• cron 式ベースのスケジュール オプションには cron を使います。 cronjob を参照してください。

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

cron間隔を使用する場合は、cronjob式を使用して更新時刻を定義できます。

day

Supported values: monday、 tuesday、 wednesday、 thursday、 friday、saturday、または sunday

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

time

形式: hh:mm

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

cronjob

サポートされる値: cron 構文または自然な表現での有効な cron 式。

クーロン構文では、スペースで分けられた 5 つのフィールドがあり、各フィールドは時間の単位を表わします。

┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)
│ │ │ │ │
* * * * *

例: 0 9 * * *、every day at 5pm

0 9 * * * は "毎日午前 9 時" に相当します。 every day at 5pm は 0 17 * * * と等価です。

cronjob 間隔を使うには、cron 型のスケジュールが必要です。

# Basic `dependabot.yml` file for cronjob

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 based on `cronjob` value
    schedule:
      interval: "cron"
      cronjob: "0 9 * * *"

# Basic `dependabot.yml` file for cronjob

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 based on `cronjob` value
    schedule:
      interval: "cron"
      cronjob: "0 9 * * *"

timezone

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

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

target-branch

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

Dependabot 既定の動作:

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

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

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

exclude-paths

マニフェストおよび依存関係をスキャンする際に Dependabot が無視するディレクトリおよびファイルのパスを指定するために使用します。 このオプションは、テスト資産、ベンダー コード、特定のファイルなど、特定の場所にある依存関係の更新を防ぐ場合に役立ちます。

Dependabot 既定の動作:

• このオプションで除外されない限り、指定された directory 内のすべてのディレクトリとファイルは更新スキャンに含まれます。

exclude-paths が定義されている場合：

• 指定されたパスに一致するすべてのファイルとディレクトリは、指定された package-ecosystem エントリの更新スキャン中に無視されます。

再帰マッチング用の ** や単一セグメントのワイルドカード用の * などの glob パターンがサポートされています。 パターンは、更新構成で指定された directory に対する相対パスになります。 各エコシステムは独自の exclude-paths 設定を持つことができます。

Example

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    exclude-paths:
      - "src/test/assets"
      - "vendor/**"
      - "src/*.js"
      - "src/test/helper.js"

# Sample patterns that can be used-

# Pattern: docs/*.json
# Matches: docs/foo.json, docs/bar.json

# Pattern: *.lock
# Matches: Gemfile.lock, package.lock, foo.lock (in any directory)

# Pattern: test/**
# Matches: test/foo.rb, test/bar/baz.rb, test/any/depth/file.txt

# Pattern: config/settings.yml
# Matches: config/settings.yml

# Pattern: **/*.md
# Matches: README.md, docs/guide.md, any/depth/file.md

# Pattern: src/*
# Matches: src/main.rb, src/app.js
# Does NOT match: src/utils/helper.rb

# Pattern: hidden/.*
# Matches: hidden/.env, hidden/.secret

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    exclude-paths:
      - "src/test/assets"
      - "vendor/**"
      - "src/*.js"
      - "src/test/helper.js"

# Sample patterns that can be used-

# Pattern: docs/*.json
# Matches: docs/foo.json, docs/bar.json

# Pattern: *.lock
# Matches: Gemfile.lock, package.lock, foo.lock (in any directory)

# Pattern: test/**
# Matches: test/foo.rb, test/bar/baz.rb, test/any/depth/file.txt

# Pattern: config/settings.yml
# Matches: config/settings.yml

# Pattern: **/*.md
# Matches: README.md, docs/guide.md, any/depth/file.md

# Pattern: src/*
# Matches: src/main.rb, src/app.js
# Does NOT match: src/utils/helper.rb

# Pattern: hidden/.*
# Matches: hidden/.env, hidden/.secret

この例では、 Dependabot は、 src/test/assets ディレクトリ、 vendor/のすべてのファイル、 src/のすぐ下にあるすべての JavaScript ファイル、および更新プログラムのスキャン時に src/test/helper.js 特定のファイルを無視します。

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、および uv

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

Dependabot 既定の動作:

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

versioning-strategyが定義されている場合、Dependabotは指定された戦略を使用します。

たとえば、現在のバージョンが 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

バージョン管理タグ

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

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 アクセスするために使用できる認証の詳細 (GitLab または Bitbucket によってホストされているレジストリを含む) を指定します。

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

# 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 を含める必要があります。

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

　　　 typeと認証の詳細

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

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

Dependabotの OIDC サポートの詳細については、OpenID Connect と Dependabot のプライベート レジストリへのアクセスの構成 を参照してください。

url および replaces-base

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