Anpassen von Dependabot-Pull-Requests an deine Prozesse

Es gibt verschiedene Möglichkeiten, Ihre Dependabot Pull-Anforderungen anzupassen, damit sie ihren eigenen internen Prozessen besser entsprechen.

Um beispielsweise die Pull Requests von Dependabot in Ihre CI/CD-Pipelines zu integrieren, kann es benutzerdefinierte Labels auf Pull Requests anwenden, die Sie dann zum Auslösen von Action-Workflows verwenden können.

Es gibt verschiedene Anpassungsoptionen, die alle in Kombination verwendet und pro Paketökosystem angepasst werden können.

Automatisches Hinzufügen zugewiesener Personen

Standardmäßig erstellt Dependabot Pull Requests ohne zugewiesene Personen.

Um Pull Requests automatisch einem bestimmten Sicherheitsteam zuzuweisen, kannst du assignees verwenden, um diese Werte pro Paketökosystem festzulegen.

In der folgenden dependabot.yml-Beispieldatei wird die npm-Konfiguration so geändert, dass alle mit Versions- und Sicherheitsupdates für npm erstellten Pull Requests Folgendes aufweisen:

Eine Person (user-name), die den Pull Requests automatisch zugewiesen wird

YAML

# `dependabot.yml` file with
#  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 assignees
    assignees:
      - "user-name"

# `dependabot.yml` file with
#  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 assignees
    assignees:
      - "user-name"

Automatisches Hinzufügen von Prüfenden

Standardmäßig erstellt Dependabot Pull Requests ohne Reviewer.

Um sicherzustellen, dass die Sicherheitsupdates Ihres Projekts umgehend vom zuständigen Team bearbeitet werden, können Sie Reviewer mithilfe einer CODEOWNERS-Datei automatisch zu Dependabot Pull Requests hinzufügen. Weitere Informationen findest du unter Informationen zu Code-Eigentümern.

Bezeichnen von Pull Requests mit benutzerdefinierten Bezeichnungen

Standardmäßig erstellt Dependabot Pull Requests mit der Bezeichnung dependencies.

Dependabot wendet auch eine Ökosystembezeichnung an, wie javaz. B. , npmoder github-actions, um Anforderungen abzurufen. Dependabot fügt sowohl die dependencies Bezeichnung als auch die Ökosystembezeichnung allen Pull-Anforderungen hinzu, einschließlich Updates für einzelne Ökosysteme, um die Filterung und Triagierung zu verbessern.

Dependabot erstellt die Standardbezeichnungen, die sie auf Pullanforderungen anwendet, wenn sie noch nicht im Repository vorhanden sind. Wenn Sie benutzerdefinierte Bezeichnungen anstelle der Standardwerte verwenden möchten, können Sie die labels Option in Ihrer dependabot.yml Datei pro Paketökosystem festlegen. Dadurch werden die Standardwerte überschrieben. Weitere Informationen findest du unter Verwalten von Labels und labels.

Wenn im Repository SemVer-Kennzeichnungen vorhanden sind, wendet Dependabot diese ebenfalls automatisch an, um die Art der Versionsaktualisierung anzugeben (major, minor oder patch). Diese Bezeichnungen werden zusätzlich zu allen benutzerdefinierten Bezeichnungen angewendet, die Sie definieren.

Du kannst labels verwenden, um die Standardbezeichnungen zu überschreiben und deine eigenen benutzerdefinierten Bezeichnungen pro Paketökosystem anzugeben. Das ist nützlich, wenn Sie zum Beispiel Folgendes tun möchten:

Verwenden von Bezeichnungen, um bestimmten Pull Requests eine Priorität zuzuweisen
Verwenden Sie Bezeichnungen, um einen anderen Workflow wie das automatische Hinzufügen der Pull Requests auf ein Projektboard auszulösen.

In der folgenden dependabot.yml-Beispieldatei wird die npm-Konfiguration so geändert, dass alle mit Versions- und Sicherheitsupdates für npm erstellten Pull Requests benutzerdefinierte Bezeichnungen aufweisen.

YAML

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

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

Das Festlegen dieser Option wirkt sich auch auf Pull Requests für Sicherheitsupdates für die Manifestdateien dieses Paket-Managers aus, es sei denn, du verwendest target-branch, um nach Versionsupdates auf einer nicht standardmäßigen Verzweigung zu suchen.

Siehe auch labels.

Hinzufügen eines Präfixes zu Commitnachrichten

Standardmäßig versucht Dependabot, Ihre Präferenzen für Commit-Nachrichten zu erkennen und ähnliche Muster zu nutzen. Darüber hinaus füllt Dependabot die Titel von Pull-Requests anhand der Commit-Nachrichten aus.

Sie können Ihr eigenes Präfix für die Commit-Nachrichten (und die Titel von Pull Requests) von Dependabot für ein bestimmtes Paketökosystem angeben. Das kann beispielsweise beim Ausführen von Automatisierungen hilfreich sein, die Commitnachrichten oder die Titel von Pull Requests verarbeiten.

Um deine Einstellungen explizit anzugeben, verwende commit-message zusammen mit den folgenden unterstützten Optionen:

prefix:
- Gibt ein Präfix für alle Commitnachrichten an.
- Das Präfix wird zudem am Anfang des Pull-Request-Titels hinzugefügt.
prefix-development:
- Gibt ein separates Präfix für alle Commit-Nachrichten an, die Entwicklungsabhängigkeiten aktualisieren, wie sie vom Paket-Manager oder Ökosystem definiert sind.
- Unterstützt für bundler, , composer, mix, maven, npm, und pip``uv.
include: "scope":
- Gibt an, dass auf jedes Präfix die Abhängigkeitstypen deps oder deps-dev folgen, die im Commit aktualisiert wurden.

Im folgenden Beispiel werden verschiedene Optionen veranschaulicht, die für jedes Paketökosystem angepasst sind:

YAML

# Customize commit messages

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    commit-message:
      # Prefix all commit messages with "npm: "
      prefix: "npm"

  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"
    commit-message:
      # Prefix all commit messages with "[docker] " (no colon, but a trailing whitespace)
      prefix: "[docker] "

  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"
    # Prefix all commit messages with "Composer" plus its scope, that is, a
    # list of updated dependencies
    commit-message:
      prefix: "Composer"
      include: "scope"

  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    # Include a list of updated dependencies
    # with a prefix determined by the dependency group
    commit-message:
      prefix: "pip prod"
      prefix-development: "pip dev"

# Customize commit messages

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    commit-message:
      # Prefix all commit messages with "npm: "
      prefix: "npm"

  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"
    commit-message:
      # Prefix all commit messages with "[docker] " (no colon, but a trailing whitespace)
      prefix: "[docker] "

  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"
    # Prefix all commit messages with "Composer" plus its scope, that is, a
    # list of updated dependencies
    commit-message:
      prefix: "Composer"
      include: "scope"

  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    # Include a list of updated dependencies
    # with a prefix determined by the dependency group
    commit-message:
      prefix: "pip prod"
      prefix-development: "pip dev"

Siehe auch commit-message.

Zuordnen von Pull Requests zu einem Meilenstein

Meilensteine helfen dir, den Fortschritt von Gruppen von Pull Requests oder Issues zu einem Projektziel oder einem Release nachzuverfolgen. Mit Dependabot können Sie die Option milestone verwenden, um Pull Requests für Abhängigkeitsaktualisierungen einem bestimmten Meilenstein zuzuordnen.

Du musst den numerischen Bezeichner des Meilensteins und nicht seine Bezeichnung angeben. Den numerischen Bezeichner kannst du im letzten Teil der Seiten-URL nach milestone finden. Beispiel: Der numerische Bezeichner des Meilensteins für https://github.com/<org>/<repo>/milestone/3 lautet 3.

YAML

# Specify a milestone for pull requests

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # Associate pull requests with milestone "4"
    milestone: 4

# Specify a milestone for pull requests

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # Associate pull requests with milestone "4"
    milestone: 4

Weitere Informationen findest du außerdem unter milestone und Informationen zu Meilensteinen.

Pull-Request-Branchnamen anpassen

Dependabot generiert eine Verzweigung für jede Pullanforderung. Jeder Branchname enthält dependabot sowie den Namen des Paket-Managers und die zu aktualisierenden Abhängigkeit. Standardmäßig werden diese Teile des Branchnamens durch ein /-Symbol wie im folgenden Beispiel getrennt:

dependabot/npm_and_yarn/next_js/acorn-6.4.1

Sie können Verzweigungsnamen mithilfe der pull-request-branch-name Option mit den folgenden Parametern anpassen: separator, , prefix, max-length, , word-separatorund branch-name-case``template. Alle Optionen sind kompositorierbar, und Sie können sie kombinieren. Die vollständige Referenz der einzelnen Parameter finden Sie unter pull-request-branch-name.

Kombinieren von Formatierungsoptionen

Sie können separator, word-separator, branch-name-case, max-length und template kombinieren, um Branch-Namen zu erzeugen, die den Anforderungen Ihres Systems entsprechen. Beispiel: Docker-Tagkompatibilität, Azure Container Registry Benennung oder Kubernetes-Verzweigungslängenbeschränkungen.

Wenn template zusammen mit anderen Optionen gesetzt wird, wird die Formatierung nach dem Rendern der Vorlage in dieser Reihenfolge in der Nachbearbeitung angewendet: Ersetzung von Trennzeichen, Ersetzung von Worttrennzeichen, Umwandlung der Groß-/Kleinschreibung und anschließend Kürzung auf die maximale Länge.

YAML

# Combine template with formatting options

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    pull-request-branch-name:
      template: "{prefix}/{package_manager}/{dependency}-{version}"
      separator: "-"
      word-separator: "-"
      branch-name-case: "lowercase"
      max-length: 80

# Combine template with formatting options

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    pull-request-branch-name:
      template: "{prefix}/{package_manager}/{dependency}-{version}"
      separator: "-"
      word-separator: "-"
      branch-name-case: "lowercase"
      max-length: 80

Vor (Standard): dependabot/npm_and_yarn/Lodash-4.17.21
Nach (mit obiger Konfiguration): dependabot-npm-and-yarn-lodash-4.17.21

Wenn ein Verzweigungsname max-length überschreitet, wird er mit einem Hash-Suffix gekürzt, um die Eindeutigkeit zu wahren.

Vollständiges Beispiel mit Multiökosystemgruppen

Im Folgenden dependabot.yml werden alle verfügbaren Optionen in verschiedenen Ökosystemen veranschaulicht, einschließlich konfiguration von Gruppen mit mehreren Ökosystemen:

YAML

# Full example demonstrating all branch name options

version: 2

multi-ecosystem-groups:
  infrastructure:
    schedule:
      interval: "weekly"
    pull-request-branch-name:
      template: "{prefix}/infra/{name}"
      word-separator: "-"
      branch-name-case: "lowercase"

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    pull-request-branch-name:
      separator: "-"
      word-separator: "-"
      branch-name-case: "lowercase"
    groups:
      frontend-deps:
        patterns: ["react*", "next*"]

  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "monthly"
    pull-request-branch-name:
      template: "{prefix}/{package_manager}/{dependency}-{version}"
      max-length: 60

  - package-ecosystem: "pip"
    directory: "/backend"
    schedule:
      interval: "weekly"
    pull-request-branch-name:
      prefix: "deps"
      branch-name-case: "lowercase"
    groups:
      django-deps:
        patterns: ["django*"]

  # These entries participate in the "infrastructure" multi-ecosystem group
  - package-ecosystem: "docker"
    directory: "/infra"
    patterns: ["nginx", "redis", "postgres"]
    multi-ecosystem-group: "infrastructure"

  - package-ecosystem: "terraform"
    directory: "/infra"
    patterns: ["hashicorp/*"]
    multi-ecosystem-group: "infrastructure"

# Full example demonstrating all branch name options

version: 2

multi-ecosystem-groups:
  infrastructure:
    schedule:
      interval: "weekly"
    pull-request-branch-name:
      template: "{prefix}/infra/{name}"
      word-separator: "-"
      branch-name-case: "lowercase"

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    pull-request-branch-name:
      separator: "-"
      word-separator: "-"
      branch-name-case: "lowercase"
    groups:
      frontend-deps:
        patterns: ["react*", "next*"]

  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "monthly"
    pull-request-branch-name:
      template: "{prefix}/{package_manager}/{dependency}-{version}"
      max-length: 60

  - package-ecosystem: "pip"
    directory: "/backend"
    schedule:
      interval: "weekly"
    pull-request-branch-name:
      prefix: "deps"
      branch-name-case: "lowercase"
    groups:
      django-deps:
        patterns: ["django*"]

  # These entries participate in the "infrastructure" multi-ecosystem group
  - package-ecosystem: "docker"
    directory: "/infra"
    patterns: ["nginx", "redis", "postgres"]
    multi-ecosystem-group: "infrastructure"

  - package-ecosystem: "terraform"
    directory: "/infra"
    patterns: ["hashicorp/*"]
    multi-ecosystem-group: "infrastructure"

Diese Konfiguration erstellt die folgenden Branch-Namen:

Szenario	Strategy	Verzweigungsname
lodash npm update	Solo	`dependabot-npm-and-yarn-lodash-4.17.21`
npm frontend-deps Gruppenaktualisierung	Gruppiert	`dependabot-npm-and-yarn-frontend-deps-fc93691fd4`
nginx solo Docker-Aktualisierung	Solo	`dependabot/docker/nginx-1.25.0`
pip Django aktualisieren	Solo	`deps/pip/django-4.2.1`
pip django-deps Gruppenaktualisierung	Gruppiert	`deps/pip/django-deps-a1b2c3d4e5`
Ökosystemübergreifende Infrastrukturgruppe (Docker + Terraform)	Multiökosystem	`dependabot/infra/infrastructure-fc93691fd4`

Hinweis

Für Gruppen mit mehreren Ökosystemen:

Das pull-request-branch-name des Eintrags multi-ecosystem-groups steuert den gruppierten, ökosystemübergreifenden PR-Branch-Namen.
Einzelne updates Einträge, die multi-ecosystem-group angeben, können nicht ein eigenes pull-request-branch-name haben. Die Konfiguration auf Gruppenebene hat Vorrang und ist die einzige Konfiguration, die für diese Einträge verwendet wird.

{package_manager} ist in Vorlagen für Gruppen mit mehreren Ökosystemen nicht verfügbar, da die Gruppe mehrere Ökosysteme umfasst.

Ein Inhaltsdigest wird immer automatisch an Multi-Ökosystem-Gruppenzweige angefügt, um die Eindeutigkeit zu gewährleisten.

So wird die Konfiguration von Branchnamen angewendet

Die Konfiguration erfolgt pro Update-Eintrag: Jeder separate package-ecosystem Eintrag kann einen eigenen Branch-Namen konfiguriert haben. Einträge, die einer Gruppe mit mehreren Ökosystemen zugewiesen sind, verwenden stattdessen die Konfiguration auf Gruppenebene.
Vorhandene PRs sind nicht betroffen: Änderungen gelten nur für neu erstellte PRs.
Das Standardverhalten ist unverändert: Wenn Sie keine Optionen konfigurieren, bleiben Verzweigungsnamen genau wie heute.

Ausrichten von Pull Requests auf einen nicht standardmäßigen Branch

Standardmäßig sucht Dependabot im Standardbranch nach Manifestdateien und erstellt Pull Requests für Updates an den Standardbranch.

Im Allgemeinen ist es am sinnvollsten, die Prüfungen und Aktualisierungen von Dependabot im Standardbranch zu belassen. In manchen Fällen muss jedoch ein anderer Zielzweig angegeben werden. Wenn beispielsweise die Prozesse Ihres Teams erfordern, dass Sie Updates zunächst auf einem Nicht-Produktions-Branch testen und validieren, können Sie target-branch verwenden, um einen anderen Branch anzugeben, gegen den Dependabot Pull Requests erstellt.

Hinweis

Dependabot erstellt Pull Requests für Sicherheitsupdates nur gegen den Standard-Branch. Wenn du target-branch verwendest, werden alle Konfigurationseinstellungen für diesen Paket-Manager nur auf Versionsupdates und nicht auf Sicherheitsupdates angewendet.

YAML

# Specify a non-default branch for pull requests for pip

version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    # Raise pull requests for version updates
    # to pip against the `develop` branch
    target-branch: "develop"
    # Labels on pull requests for version updates only
    labels:
      - "pip dependencies"

  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      # Check for npm updates on Sundays
      day: "sunday"
    # Labels on pull requests for security and version updates
    labels:
      - "npm dependencies"

# Specify a non-default branch for pull requests for pip

version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    # Raise pull requests for version updates
    # to pip against the `develop` branch
    target-branch: "develop"
    # Labels on pull requests for version updates only
    labels:
      - "pip dependencies"

  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      # Check for npm updates on Sundays
      day: "sunday"
    # Labels on pull requests for security and version updates
    labels:
      - "npm dependencies"

Siehe auch target-branch.

Anpassen von Dependabot-Pull-Requests an deine Prozesse

Wer kann dieses Feature verwenden?

In diesem Artikel

Automatisches Hinzufügen zugewiesener Personen

Automatisches Hinzufügen von Prüfenden

Bezeichnen von Pull Requests mit benutzerdefinierten Bezeichnungen

Hinzufügen eines Präfixes zu Commitnachrichten

Zuordnen von Pull Requests zu einem Meilenstein

Pull-Request-Branchnamen anpassen

Kombinieren von Formatierungsoptionen

Vollständiges Beispiel mit Multiökosystemgruppen

So wird die Konfiguration von Branchnamen angewendet

Ausrichten von Pull Requests auf einen nicht standardmäßigen Branch