Dependabot の既定では、新しい pull request が開かれ、各依存関係が更新されます。 セキュリティ更新プログラムを有効にすると、脆弱な依存関係が見つかったときに新しい pull request が開かれます。 1 つ以上のエコシステムのバージョン更新プログラムを構成すると、依存関係の新しいバージョンがリリースされたときに、dependabot.yml ファイルに定義されている頻度で新しい pull request が開かれます。
プロジェクトに多くの依存関係がある場合、レビューとマージが必要な Dependabot の pull request が非常に多くなり、すぐに管理が困難になる可能性があります。
Dependabot の更新 pull request をプロセスに合わせて最適化するには、実装できるカスタマイズ オプションがいくつかあります。次に例を示します。
- Dependabot で
scheduleを使って依存関係の新しいバージョンをチェックする頻度を制御します。 groupsを使って、重要なプログラムを優先します。
依存関係の更新の頻度とタイミングを制御する
Dependabot は、構成ファイルで設定された頻度でバージョン更新のチェックを実行します。必須フィールド schedule.interval は、daily、weekly、monthly、quarterly、semiannually、yearly、または cron に設定する必要があります (cronjob を参照)。
Dependabot の既定では、依存関係の更新をチェックして pull request を生成するランダムな時間を割り当てることで、ワークロードが分散されます。
ただし、気が散らないようにするため、またはバージョン更新プログラムを確認して対処するために時間とリソースをより適切に整理するには、頻度とタイミングを変更すると便利な場合があります。 たとえば、Dependabot で、更新プログラムのチェックを毎日ではなく毎週実行し、チームのトリアージ セッションの前に pull request が確実に生成されるようにすることもできます。
依存関係の更新頻度とタイミングの変更
schedule をオプションと組み合わせて使うと、Dependabot によるバージョン更新プログラムのチェック頻度とタイミングを変更できます。
次の dependabot.yml ファイル例では、npm 構成を変更して、Dependabot が毎週火曜日の日本標準時間 02:00 (UTC +09:00) に npm 依存関係のバージョン更新プログラムをチェックするように指定しています。
# `dependabot.yml` file with
# customized schedule for version updates
version: 2
updates:
# Keep npm dependencies up to date
- package-ecosystem: "npm"
directory: "/"
# Check the npm registry every week on Tuesday at 02:00 Japan Standard Time (UTC +09:00)
schedule:
interval: "weekly"
day: "tuesday"
time: "02:00"
timezone: "Asia/Tokyo"
# `dependabot.yml` file with
# customized schedule for version updates
version: 2
updates:
# Keep npm dependencies up to date
- package-ecosystem: "npm"
directory: "/"
# Check the npm registry every week on Tuesday at 02:00 Japan Standard Time (UTC +09:00)
schedule:
interval: "weekly"
day: "tuesday"
time: "02:00"
timezone: "Asia/Tokyo"
「schedule」も参照してください。
依存関係の更新のためのクールダウン期間を設定する
cooldown をオプションの組み合わせと併用して、Dependabot がバージョン更新の pull request を作成するタイミングを制御できます。
以下のサンプル dependabot.yml ファイルでは、requests、numpy、プレフィックスが pandas または django である依存関係にクールダウン期間が適用されていますが、exclude リストで除外されている pandas (完全一致) という依存関係には適用されていません。
version: 2
updates:
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "daily"
cooldown:
default-days: 5
semver-major-days: 30
semver-minor-days: 7
semver-patch-days: 3
include:
- "requests"
- "numpy"
- "pandas*"
- "django"
exclude:
- "pandas"
version: 2
updates:
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "daily"
cooldown:
default-days: 5
semver-major-days: 30
semver-minor-days: 7
semver-patch-days: 3
include:
- "requests"
- "numpy"
- "pandas*"
- "django"
exclude:
- "pandas"
- クールダウンの日数は 1 から 90 の間で指定する必要があります。
cooldownで使用できるincludeリストとexcludeリストの項目数の上限は、それぞれ 150 個です。
メモ
クールダウン期間のすべての依存関係を考慮するには、次の方法があります。
includeオプションを省略すると、すべての依存関係にクールダウンが適用されます。includeに"*"を使うと、クールダウン設定がすべてに適用されます。 特定の依存関係****のみをクールダウンの対象外にするには、excludeオプションの使用をお勧めします。
SemVer はほとんどのパッケージ マネージャーでサポートされています。 クールダウン中の依存関係の新しいバージョンへの更新は、次のように延期されます。
- メジャー更新: 30 日間延期されます (
semver-major-days: 30)。 - マイナー更新: 7 日間延期されます (
semver-minor-days: 7)。 - パッチ更新: 3 日間延期されます (
semver-patch-days: 3)。
cooldown も参照してください。
重要な更新プログラムを優先する
groups を使うと、複数の依存関係の更新を 1 つの pull request に統合できます。 こうすることで、リスクの高い更新プログラムにレビュー時間を集中させ、マイナー バージョン更新プログラムのレビューに費やす時間を最小限に抑えることができます。 たとえば、開発の依存関係に対するマイナーまたはパッチ更新プログラムの更新プログラムを 1 つの pull request に結合し、コードベースの主要領域に影響を与えるセキュリティまたはバージョン更新プログラムを担当する専用グループを用意することができます。
個々のパッケージ エコシステムごとにグループを構成する必要があります。その後、次の条件の組み合わせを使って、パッケージ エコシステムごとに複数のグループを作成できます。
- Dependabot の更新プログラムの種類:
applies-to - 依存関係の種類:
dependency-type。 - 依存関係の名前:
patternsとexclude-patterns - セマンティック バージョニング レベル:
update-types
各条件でサポートされているすべての値を確認するには、「groups」を参照してください。
条件を使って依存関係のグループを作成する複数の方法の例を次に示します。
例 1: 3 つのバージョン更新プログラム グループ
この例では、dependabot.yml ファイルは次のようになります。
- "
production-dependencies"、"development-dependencies"、"rubocop" という 3 つのグループを作成します。 patternsとdependency-typeを使って、グループに依存関係を含めます。exclude-patternsを使って、グループから 1 つの依存関係 (または複数の依存関係) を除外します。
version: 2
updates:
# Keep bundler dependencies up to date
- package-ecosystem: "bundler"
directory: "/"
schedule:
interval: "weekly"
groups:
production-dependencies:
dependency-type: "production"
development-dependencies:
dependency-type: "development"
exclude-patterns:
- "rubocop*"
rubocop:
patterns:
- "rubocop*"
その結果、次のような影響が出ています。
- バージョン更新プログラムは依存関係の種類ごとにグループ化されます。
- パターン
rubocop*と一致する開発依存関係は、development-dependenciesグループから除外されます。 - 代わりに、
rubocop*と一致する開発依存関係がrubocopグループに含まれます。 グループ化により、rubocop*と一致する開発依存関係がproduction-dependenciesグループに含まれます。 - さらに、
applies-toキーが存在しないため、すべてのグループは既定でバージョン更新プログラムのみに適用されます。
例 2: 依存関係が除外された、グループ化された更新プログラム
この例では、dependabot.yml ファイルは次のようになります。
- カスタマイズされた Bundler 構成の一部として、"
support-dependencies" というグループを作成します。 - 1 つの依存関係 (または複数の依存関係) の名前と一致する
patternsを使って、グループに依存関係を含めます。 - 1 つの依存関係 (または複数の依存関係) の名前と一致する
exclude-patternsを使って、グループから依存関係を除外します。 applies-to: version-updatesが使われているため、グループ化をバージョン更新プログラムにのみ適用します。
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
support-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-*"
その結果、次のような影響が出ています。
- Bundler の依存関係の大部分は、ワイルドカード ("*") パターンにより、
support-dependenciesグループに統合されます gc_ruboconfigやgocardless-*と一致する依存関係はグループから除外され、Dependabot により、これらの依存関係に対して 1 つの pull request が引き続き生成されます。 これが役立つのは、これらの依存関係の更新プログラムを詳細に確認する必要がある場合です。support-dependenciesの場合、バージョン更新プログラムに対してのみ、Dependabot によって pull request が生成されます。
例 3: メジャー更新プログラムの個別の pull request と、マイナーまたはパッチ更新プログラムのグループ化
この例では、dependabot.yml ファイルは次のようになります。
- "
angular" というグループを作成します。 - 依存関係の名前と一致する
patternsを使って、グループに依存関係を含めます。 - そのグループの
minorまたはpatchの更新プログラムのみを含めるには、update-typeを使います。 applies-to: version-updatesが使われているため、グループ化をバージョン更新プログラムにのみ適用します。
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
groups:
# Specify a name for the group, which will be used in pull request titles
# and branch names
angular:
applies-to: version-updates
patterns:
- "@angular*"
update-types:
- "minor"
- "patch"
その結果、次のような影響が出ています。
- マイナーまたはパッチ更新プログラムがあるすべての Angular 依存関係に対して、Dependabot によってグループ化された pull request が作成されます。
- すべてのメジャー更新プログラムは引き続き個別の pull request として生成されます。
例 4: マイナーまたはパッチ更新プログラムのグループ化された pull request と、メジャー更新プログラムの pull request なし
この例では、dependabot.yml ファイルは次のようになります。
- "
angular" と "minor-and-patch" という 2 つのグループを作成します。 applies-toを使うと、最初のグループがバージョン更新プログラムのみに適用され、2 つ目のグループがセキュリティ更新プログラムのみに適用されます。- 両方のグループの
minorまたはpatchの更新プログラムのみを含めるには、update-typeを使います。 @angular*パッケージのmajorバージョンへの更新プログラムを除外するには、ignore条件を使います。
version: 2
updates:
# Keep npm dependencies up to date
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
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"]
その結果、次のような影響が出ています。
- Angular 依存関係のマイナーおよびパッチ バージョン更新プログラムは、1 つの pull request にグループ化されます。
- Angular 依存関係のマイナーおよびパッチのセキュリティ更新プログラムも、1 つの pull request にグループ化されます。
- Angular のメジャー更新プログラムに対しては、Dependabot によって自動的に pull request は開かれません。