Optimizing the creation of pull requests for Dependabot version updates

Learn how to streamline and efficiently manage your Dependabot pull requests.

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

Users with write access

この記事の内容

By default, Dependabot opens a new pull request to update each dependency. When you enable security updates, new pull requests are opened when a vulnerable dependency is found. When you configure version updates for one or more ecosystems, new pull requests are opened when new versions of dependencies are available, with the frequency defined in the dependabot.yml file.

If your project has many dependencies, you might find that you have a very large number of Dependabot pull requests to review and merge, which can quickly become difficult to manage.

There are a couple of customization options you can implement to optimize Dependabot update pull requests to align with your processes, such as:

  • Controlling the frequency with which Dependabot checks for newer versions of your dependencies with schedule.
  • Prioritize meaningful updates with groups.

Controlling the frequency and timings of dependency updates

Dependabot runs its checks for version updates at a frequency set by you in the configuration file, where the required field, schedule.interval, must be set to daily, weekly, monthly, quarterly, semiannually, yearly, or cron (see cronjob).

By default, Dependabot balances its workload by assigning a random time to check and raise pull requests for dependency updates.

However, to reduce distraction, or to better organize time and resources for reviewing and addressing version updates, you might find it useful to modify the frequency and timings. For example, you may prefer Dependabot to run weekly rather than daily checks for updates, and at a time that ensures pull requests are raised before for your team's triage session.

Modifying the frequency and timings for dependency updates

You can use schedule with a combination of options to modify the frequency and timings of when Dependabot checks for version updates.

The example dependabot.yml file below changes the npm configuration to specify that Dependabot should check for version updates to npm dependencies every Tuesday at 02:00 Japanese Standard Time (UTC +09:00).

YAML
# `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"

See also schedule.

Setting up a cooldown period for dependency updates

You can use cooldown with a combination of options to control when Dependabot creates pull requests for version updates.

The example dependabot.yml file below shows a cooldown period being applied to the dependencies requests, numpy, and those prefixed with pandas or django, but not to the dependency called pandas (exact match), which is excluded via the exclude list.

YAML
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"
  • The number of cooldown days must be between 1 and 90.
  • The maximum allowed items limit in include and exclude lists, which can be used with cooldown, is 150 each.

メモ

To consider all dependencies for a cooldown period, you can:

  • Omit the include option which applies cooldown to all dependencies.
  • Use "*" in include to apply the cooldown settings to everything. We recommend the use of exclude to only exclude specific dependencies from cooldown settings.

SemVer is supported for most package managers. Updates to new versions for dependencies in cooldown are deferred as follows:

  • Major updates: Delayed by 30 days (semver-major-days: 30).
  • Minor updates: Delayed by 7 days (semver-minor-days: 7).
  • Patch updates: Delayed by 3 days (semver-patch-days: 3).

See also cooldown.

Prioritizing meaningful updates

You can use groups to consolidate updates for multiple dependencies into a single pull request. This helps you focus your review time on higher risk updates, and minimize the time spent reviewing minor version updates. For example, you can combine updates for minor or patch updates for development dependencies into a single pull request, and have a dedicated group for security or version updates that impact a key area of your codebase.

You must configure groups per individual package ecosystem, then you can create multiple groups per package ecosystem using a combination of criteria:

  • Dependabot update type: applies-to
  • Type of dependency: dependency-type.
  • Dependency name: patterns and exclude-patterns
  • Semantic versioning levels: update-types

To see all supported values for each criterion, see groups.

The below examples present several different methods to create groups of dependencies using the criteria.

例 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 は開かれません。