依存関係の更新をカスタマイズする

この記事の内容

Dependabot が依存関係を維持する方法をカスタマイズできます。

この機能を使用できるユーザー

People with write permissions to a repository can configure Dependabot for the repository.

依存関係の更新のカスタマイズについて

バージョン アップデートを有効にすると、dependabot.yml ファイルにその他のオプションを追加することで、Dependabot を使って依存関係を維持する方法をカスタマイズできます。 たとえば、次のことが可能です。

  • バージョン アップデートの pull request をオープンする曜日を指定する (schedule.day)
  • 各パッケージ マネージャーのレビュー担当者、担当者、ラベルを設定する: reviewers、assignees、labels
  • 依存関係のグループを (パッケージ エコシステムごとに) 作成して、Dependabot が 1 つの pull request で依存関係のグループを更新できるようにする: groups
  • 各マニフェスト ファイルの変更に対するバージョン管理戦略を定義する (versioning-strategy)
  • バージョン アップデートの pull requests オープンする回数を、既定の 5 回から最大の回数に変更する (open-pull-requests-limit)
  • バージョン アップデートの pull request をオープンして、既定のブランチの代わりに特定のブランチをターゲットにする (target-branch)

構成オプションの詳細については「dependabot.yml ファイルの構成オプション」を参照してください。

リポジトリ内の dependabot.yml ファイルを更新すると、Dependabot によって、新しい構成で、すぐにチェックが実行されます。 数分以内に、 [Dependabot] タブに依存関係の更新済みリストが表示されます。リポジトリにある依存関係が多い場合は、時間がかかることがあります。 バージョン更新に関する新しいプルリクエストが表示されることもあります。 詳しくは、「バージョン更新用に設定された依存関係を一覧表示する」を参照してください。

設定変更によるセキュリティアップデートへの影響

dependabot.yml ファイルをカスタマイズしていると、セキュリティ アップデートに対して発行された pull request の変更点に気づくかもしれません。 これらのプルリクエストは、Dependabot スケジュールではなく、常に依存関係のセキュリティアドバイザリによってトリガーされます。 ただし、バージョン アップデートに別のターゲット ブランチを指定していなければ、関連する構成設定は dependabot.yml ファイルから継承されます。

例については、カスタム ラベルの設定に関する以下のセクションを参照してください。

スケジュールを変更する

アップデート スケジュールを daily に設定すると、既定の 05:00 (UTC) に Dependabot で新しいバージョンのチェックが行われます。 schedule.time を使うと、アップデートのチェックを別の時刻に指定できます (hh:mm 形式)。

次の dependabot.yml ファイルの例では、npm 構成を拡張して、Dependabot で依存関係のバージョン アップデートをチェックするタイミングを指定します。

# `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 for updates at 2am UTC
    schedule:
      interval: "daily"
      time: "02:00"

レビュー担当者とアサインされた人を設定する

デフォルトでは、Dependabot は、レビュー担当者やアサインされた人なしでプルリクエストを発行します。

reviewers と assignees を使うと、パッケージ マネージャーに対して発行されたすべての pull request のレビュー担当者と担当者を指定できます。 Team を指定する場合は、その Team (Organization を含む) を @mentioning していたように、Team のフル ネームを使う必要があります。

次の dependabot.yml ファイルの例では、npm のバージョン アップデートとセキュリティ アップデートでオープンしたすべての pull request に 2 人のレビュー担当者と 1 人の担当者が存在するように、npm 構成を変更します。

# `dependabot.yml` file with
# reviews and an assignee for all npm pull requests

version: 2
updates:
  # Keep npm dependencies up to date
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # Raise all npm pull requests with reviewers
    reviewers:
      - "my-org/team-name"
      - "octocat"
    # Raise all npm pull requests with an assignee
    assignees:
      - "user-name"

カスタムラベルを設定する

既定では、Dependabot ではすべての pull request を dependencies ラベル付きで発行します。 複数のパッケージマネージャが定義されている場合、DependabotはそれぞれのPull Requestに追加のラベルを含めます。 これは、その pull request によってどの言語またはエコシステムが更新されるかを示します。たとえば、Gradle の更新には java、Git サブモジュールの更新には submodules というようになります。 Dependabotは、リポジトリ中の必要に応じて自動的にこれらのデフォルトラベルを作成します。

labels を使うと、既定のラベルを上書きして、パッケージ マネージャーに対して発行されたすべての pull request に代替ラベルを指定できます。 dependabot.yml ファイルでは新しいラベルを作成できないため、リポジトリ内に代替ラベルが既に存在している必要があります。

次の dependabot.yml ファイルの例では、npm のバージョン アップデートとセキュリティ アップデートでオープンしたすべての pull request にカスタム ラベルが存在するように、npm 構成を変更します。 また、Docker 設定を変更して、カスタムブランチに対するバージョン更新を確認し、そのカスタムブランチに対するカスタムラベルを使用してプルリクエストを発行します。 セキュリティアップデートは常にデフォルトのブランチに対して行われるため、Docker への変更はセキュリティアップデートのプルリクエストには影響しません。

注: 新しい target-branch には、更新する Dockerfile が含まれている必要があります。含まれていない場合、この変更を行うと、Docker のバージョン アップデートが無効になります。

# `dependabot.yml` file with
# customized npm configuration

version: 2
updates:
  # Keep npm dependencies up to date
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # Raise all npm pull requests with custom labels
    labels:
      - "npm dependencies"
      - "triage-board"

    # Keep Docker dependencies up to date
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"
    # Raise pull requests for Docker version updates
    # against the "develop" branch. The Docker configuration
    # no longer affects security update pull requests.
    target-branch: "develop"
    # Use custom labels on pull requests for Docker version updates
    labels:
      - "Docker dependencies"
      - "triage-board"

Dependabot version updates を 1 つの pull request にグループ化する

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

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

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

Dependabot version updates のグループのみを作成できます。 Dependabot security updates ではグループ化された更新はサポートされていません。 さらに、脆弱なパッケージに対してグループ化された pull request がある場合、Dependabot security updates は、既存のグループ pull request が同じバージョンまたはそれ以降のバージョンに対する更新である場合でも、常に個別の pull request の作成を試みます。

最初の例の dependabot.yml ファイルでは、グループに特定の依存関係を含める patterns および dependency-type オプションと、単一または複数の依存関係をグループから除外したりする exclude-patterns を組み合わせて使用します。

2 番目の例では、bundler の構成を変更して、依存関係のグループを作成します。 構成では、依存関係をグループに含めるために、依存関係 (または複数の依存関係) の名前と一致する patterns (文字列) を指定します。

3 番目の例では、解決できる最大バージョンが minor または patch であるパターン @angular* と一致するすべてのパッケージをグループにまとめます。 Dependabot は、パターンに一致しないパッケージ、またはバージョン minor または patch に更新されないすべてのパッケージに対して個別の pull request を作成します。

4 番目の例では、ignore 条件を使用して @angular* パッケージの major バージョンに対する更新プログラムを除外します。

dependabot.yml ファイルでの依存関係グループの構成の詳細については、「dependabot.yml ファイルの構成オプション」を参照してください。

パッケージ エコシステムごとにグループを構成する必要があります。

# `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 version updates の特定の依存関係を無視する

プロジェクト内の依存関係からの変更を採用する準備ができていない場合は、Dependabot を構成して、バージョン更新のpull requestを開いたときにそれらの依存関係を無視できます。 次のいずれかの方法で実行できます:

  • dependabot.yml ファイル内の依存関係に ignore オプションを構成します。 これで、特定の依存関係、バージョン、更新プログラムの種類のアップデートを無視できます。 詳しくは、「dependabot.yml ファイルの構成オプション」を参照してください。
  • バージョン更新の Dependabot pull requestで @dependabot ignore のコメント コマンドを使用します。 これで、特定の依存関係およびバージョンの種類のアップデートを無視できます。 詳しくは、「依存関係の更新に関するPull Requestを管理する」を参照してください。

依存関係を無視解除する、または無視条件を解除する場合は、無視条件を dependabot.yml ファイルから削除するか、pull requestを再度開きます。

グループ化されたバージョン更新の pull request では、@dependabot unignore のコメント コマンドも使用できます。 @dependabot unignore のコメント コマンドを使用すると、Dependabot pull requestにコメントを付けることで、次のことを行うことができます。

  • 特定の無視条件を無視解除する
  • 特定の依存関係を無視解除する
  • Dependabot の pull request において、すべての依存関係のすべての無視条件を無視解除する

注: @dependabot unignore コメント コマンドは、グループ化されたバージョンの更新に対する pull request でのみ機能します。

詳しくは、「依存関係の更新に関するPull Requestを管理する」をご覧ください。

その他の例

その他の例については「dependabot.yml ファイルの構成オプション」を参照してください。