Konfigurationsoptionen für die Datei dependabot.yml

Informationen zur Datei dependabot.yml

In der Dependabot-Konfigurationsdatei dependabot.yml wird die YAML-Syntax verwendet. Wenn du noch nicht mit YAML arbeiten und mehr erfahren möchtest, lies den Artikel zum Erlernen von YAML in fünf Minuten.

Du musst diese Datei im .github-Verzeichnis deines Repositorys speichern. Wenn du die Datei dependabot.yml hinzufügst oder aktualisierst, wird dadurch eine sofortige Überprüfung auf Versionsupdates ausgelöst. Weitere Informationen und ein Beispiel findest du unter Konfigurieren von Versionsupdates von Dependabot.

Alle Optionen, die sich auch auf Sicherheitsupdates auswirken, werden beim nächsten Mal verwendet, wenn eine Sicherheitswarnung einen Pull Request für ein Sicherheitsupdate auslöst. Weitere Informationen findest du unter Konfigurieren von Dependabot-Sicherheitsupdates.

Die Datei dependabot.yml verfügt über zwei obligatorische Schlüssel der obersten Ebene: version und updates. Du kannst optional einen registries-Schlüssel der obersten Ebene in die Datei aufnehmen. Die Datei muss mit version: 2 beginnen.

Konfigurationsoptionen für die Datei dependabot.yml

Der updates-Schlüssel der obersten Ebene ist erforderlich. Du verwendest ihn, um zu konfigurieren, wie die Versionen oder die Abhängigkeiten deines Projekts von Dependabot aktualisiert werden. Von jedem Eintrag werden die Updateeinstellungen für einen bestimmten Paket-Manager konfiguriert. Du kannst die folgenden Optionen verwenden:

Option	Erforderlich	Sicherheitsupdates	Versionsupdates	BESCHREIBUNG
package-ecosystem	X		X	Zu verwendender Paket-Manager
directory	X		X	Speicherort von Paketmanifesten
schedule.interval	X		X	Häufigkeit der Suche nach Updates
allow		X	X	Anpassen der zulässigen Updates
assignees		X	X	Für Pull Requests festzulegende zugewiesene Personen
commit-message		X	X	Commitnachrichteneinstellungen
enable-beta-ecosystems			X	Aktivieren von Ökosystemen mit Unterstützung auf Betaebene
ignore		X	X	Ignorieren bestimmter Abhängigkeiten oder Versionen
insecure-external-code-execution			X	Zulassen oder Ablehnen der Codeausführung in Manifestdateien
labels		X	X	Für Pull Requests festzulegende Bezeichnungen
milestone		X	X	Für Pull Requests festzulegende Meilensteine
open-pull-requests-limit		X	X	Beschränken der Anzahl der geöffneten Pull Requests für Versionsupdates
pull-request-branch-name.separator		X	X	Ändern des Trennzeichens für Branchnamen von Pull Requests
rebase-strategy		X	X	Deaktivieren des automatischen Rebasing
registries		X	X	Private Registrierungen, auf die Dependabot zugreifen kann
reviewers		X	X	Für Pull Requests festzulegende Reviewer
schedule.day			X	Wochentag für die Suche nach Updates
schedule.time			X	Tageszeit für die Suche nach Updates (hh:mm)
schedule.timezone			X	Zeitzone für Tageszeit (Zonenbezeichner)
target-branch			X	Branch, für den Pull Requests erstellt werden sollen
vendor			X	Aktualisieren von anbieterbezogenen oder zwischengespeicherten Abhängigkeiten
versioning-strategy		X	X	Vorgehensweise für die Aktualisierung von Manifestversionsanforderungen

Diese Optionen lassen sich grob in die folgenden Kategorien einteilen.

• Grundlegende Einrichtungsoptionen, die du in alle Konfigurationen aufnehmen musst: package-ecosystem, directory, schedule.interval.
• Optionen zum Anpassen des Updatezeitplans: schedule.time, schedule.timezone, schedule.day.
• Optionen, mit denen gesteuert wird, welche Abhängigkeiten aktualisiert werden: allow, ignore, vendor.
• Optionen, mit denen Metadaten zu Pull Requests hinzugefügt werden: reviewers, assignees, labels, milestone.
• Optionen zum Ändern des Verhaltens von Pull Requests: target-branch, versioning-strategy, commit-message, rebase-strategy, pull-request-branch-name.separator.

Darüber hinaus wird mit der Option open-pull-requests-limit die maximale Anzahl von Pull Requests für Versionsupdates geändert, die von Dependabot geöffnet werden können.

package-ecosystem

Erforderlich. Du fügst ein package-ecosystem-Element für jeden Paket-Manager hinzu, der von Dependabot auf neue Versionen hin überwacht werden soll. Das Repository muss auch ein Abhängigkeitsmanifest oder eine Sperrdatei für jeden dieser Paket-Manager enthalten. Wenn du Vendoring für einen Paket-Manager aktivieren möchtest, der dies unterstützt, müssen sich die anbieterbezogenen Abhängigkeiten im erforderlichen Verzeichnis befinden. Weitere Informationen findest du unten unter vendor.

Die folgende Tabelle zeigt für jeden Paket-Manager:

• Den YAML-Wert, der in der Datei dependabot.yml verwendet werden soll
• Die unterstützten Versionen des Paket-Managers
• Ob Abhängigkeiten in privaten Repositorys oder Registrierungen von GitHub unterstützt werden
• Ob anbieterseitige Abhängigkeiten unterstützt werden

Paket-Manager	YAML-Wert	Unterstützte Versionen	Private Repositorys	Private Registrierungen	Vendoring
Bundler	bundler	v1, v2
Cargo	cargo	v1		(Nur Git)
Composer	composer	v1, v2
Docker	docker	v1			Nicht verfügbar
Hex	mix	v1
elm-package	elm	v0.19
Git-Submodul	gitsubmodule	Nicht verfügbar			Nicht verfügbar
GitHub Actions	github-actions	Nicht verfügbar			Nicht verfügbar
Go-Module	gomod	v1
Gradle	gradle	Nicht verfügbar
Maven	maven	Nicht verfügbar
npm	npm	v6, v7, v8
NuGet	nuget	<= 4.8
pip	pip	v21.1.2
pipenv	pip	<= 2021-05-29
pip-compile	pip	6.1.0
Poetry	pip	v1
Kneipe	pub	V2
Terraform	terraform	>= 0.13, <= 1.3.x			Nicht verfügbar
yarn	npm	v1, v2, v3

Cargo

Die Unterstützung privater Registrierungen gilt für Git-Registrierungen und umfasst keine Cargo-Registrierungen.

Docker

Dependabot kann Pull Requests für Versionsupdates Metadaten aus Docker-Images hinzufügen. Die Metadaten enthalten Versionshinweise, Änderungsprotokolle und den Commitverlauf. Repositoryadministratoren können die Metadaten verwenden, um das Stabilitätsrisiko des Abhängigkeitsupdates schnell auszuwerten.

Damit Dependabot Docker-Metadaten abrufen kann, müssen Verwalter von Docker-Images die org.opencontainers.image.source-Bezeichnung ihrer Dockerfile-Datei hinzufügen und die URL des Quellrepositorys einschließen. Darüber hinaus müssen Verwalter das Repository mit den gleichen Tags versehen wie die veröffentlichten Docker-Images. Ein Beispiel dafür findest du im dependabot-fixtures/docker-with-source-Repository. Weitere Informationen zu Docker-Bezeichnungen findest du unter Erweiterungsimagebezeichnungen und BUILDX_GIT_LABELS in der Docker-Dokumentation.

Dependabot kann Docker-Imagetags in Kubernetes-Manifesten aktualisieren. Füge dem Docker-Element package-ecosystem deiner Datei vom Typ dependabot.yml für jedes Verzeichnis, das ein Kubernetes-Manifest enthält, das auf Docker-Imagetags verweist, einen Eintrag hinzu. Kubernetes-Manifeste können YAML-Dateien oder Helm-Diagramme für die Kubernetes-Bereitstellung sein. Informationen zum Konfigurieren deiner dependabot.yml-Datei für docker findest du unter package-ecosystem in Konfigurationsoptionen für die Datei dependabot.yml.

Dependabot unterstützt sowohl öffentliche als auch private Docker-Registrierungen. Eine Liste der unterstützten Registrierungen findest du unter docker-registry in Konfigurationsoptionen für die Datei dependabot.yml.

GitHub Actions

Dependabot unterstützt nur Updates für GitHub Actions über die GitHub-Repositorysyntax, z. B. durch actions/checkout@v3. Docker Hub und GitHub Packages Container registry-URLs werden derzeit nicht unterstützt.

Gradle

Dependabot führt Gradle nicht aus, unterstützt jedoch Updates folgender Dateien:

• build.gradle, build.gradle.kts (für Kotlin-Projekte)
• gradle/libs.versions.toml (für Projekte, die einen Gradle-Standardversionskatalog verwenden)
• Dateien, die über die apply-Deklaration eingefügt wurden, die dependencies im Dateinamen enthalten. Beachte, dass apply weder apply to, Rekursion noch erweiterte Syntax – z. B. apply mit mapOf bei Kotlin oder durch Eigenschaften definierte Dateinamen – unterstützt.

Maven

Dependabot führt Maven nicht aus, unterstützt jedoch Updates von pom.xml-Dateien.

NuGet-CLI

Dependabot führt die NuGet-CLI nicht aus, unterstützt jedoch die meisten Features bis Version 4.8.

pip und pip-compile

Zusätzlich zur Unterstützung von Updates von requirements.txt-Dateien unterstützt Dependabot Updates von pyproject.toml-Dateien, wenn sie dem PEP 621-Standard entsprechen.

Kneipe

Dependabot kein Update ausgeführt, wenn die Version, für die pub ein Update durchzuführen versucht, ignoriert wird. Dies gilt auch dann, wenn eine frühere Version verfügbar ist.

yarn

Dependabot unterstützt Anbieterabhängigkeiten ab Version 2.

# Basic set up for three package managers

version: 2
updates:

  # Maintain dependencies for GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

  # Maintain dependencies for npm
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

  # Maintain dependencies for Composer
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"

directory

Erforderlich. Du musst den Speicherort der Paketmanifeste für jeden Paket-Manager definieren (z. B. package.json oder Gemfile). Du definierst das Verzeichnis relativ zum Stamm des Repositorys für alle Ökosysteme mit Ausnahme von GitHub Actions. Lege für GitHub Actions das Verzeichnis auf / fest, um in .github/workflows nach Workflowdateien zu suchen.

# Specify location of manifest files for each package manager

version: 2
updates:
  - package-ecosystem: "composer"
    # Files stored in repository root
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "npm"
    # Files stored in `app` directory
    directory: "/app"
    schedule:
      interval: "weekly"

  - package-ecosystem: "github-actions"
    # Workflow files stored in the
    # default location of `.github/workflows`
    directory: "/"
    schedule:
      interval: "weekly"

schedule.interval

Erforderlich. Du musst definieren, wie oft nach neuen Versionen für jeden Paket-Manager gesucht werden soll. Standardmäßig wird von Dependabot ein zufälliger Zeitpunkt zugewiesen, zu dem alle Updates in der Konfigurationsdatei angewendet werden. Zum Festlegen einer bestimmten Zeit kannst du schedule.time und schedule.timezone verwenden.

Intervalltypen	Häufigkeit
daily	Wird an jedem Wochentag von Montag bis Freitag ausgeführt.
weekly	Wird einmal jede Woche ausgeführt. Standardmäßig erfolgt die Ausführung am Montag. Verwende schedule.day, um die Standardeinstellung zu ändern.
monthly	Wird einmal jeden Monat ausgeführt. Die Ausführung erfolgt am ersten Tag des Monats.

# Set update schedule for each package manager

version: 2
updates:

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      # Check for updates to GitHub Actions every weekday
      interval: "daily"

  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      # Check for updates managed by Composer once a week
      interval: "weekly"

allow

Standardmäßig werden alle Abhängigkeiten von Dependabot auf dem neuesten Stand gehalten, die explizit in einem Manifest definiert sind. Darüber hinaus aktualisieren Dependabot-Sicherheitsupdates auch anfällige Abhängigkeiten, die in Sperrdateien definiert sind. Du kannst allow und ignore verwenden, um anzupassen, welche Abhängigkeiten aktuell gehalten werden sollen. Dependabot sucht nach allen zulässigen Abhängigkeiten und filtert dann alle ignorierten Abhängigkeiten oder Versionen aus. Eine Abhängigkeit, die sowohl mit einer als auch einer allow und einer ignore übereinstimmt, wird ignoriert.

Verwende die Option allow, um anzupassen, welche Abhängigkeiten aktualisiert werden. Dies gilt sowohl für Versions- als auch für Sicherheitsupdates. Du kannst die folgenden Optionen verwenden:

• dependency-name: Verwende diese Option, um Updates für Abhängigkeiten mit übereinstimmenden Namen zuzulassen. Verwende optional * für die Übereinstimmung mit null oder mehr Zeichen. Für Java-Abhängigkeiten lautet das Format des dependency-name-Attributs: groupId:artifactId, zum Beispiel: org.kohsuke:github-api.

• dependency-type: Verwende diese Option, um Updates für Abhängigkeiten bestimmter Typen zuzulassen.

  Abhängigkeitstypen	Unterstützt von Paket-Managern	Zulassen von Updates
  direct	All	Alle explizit definierten Abhängigkeiten.
  indirect	bundler, pip, composer, cargo und gomod	Abhängigkeiten von direkten Abhängigkeiten (auch als Unterabhängigkeiten oder vorübergehende Abhängigkeiten bezeichnet).
  all	All	Alle explizit definierten Abhängigkeiten. Für bundler, pip, composer, cargo und gomod auch die Abhängigkeiten von direkten Abhängigkeiten.
  production	bundler, composer, mix, maven, npm, pip	Nur Abhängigkeiten in der „Produktionsabhängigkeitsgruppe“.
  development	bundler, composer, mix, maven, npm, pip	Nur Abhängigkeiten in der „Entwicklungsabhängigkeitsgruppe“.

# Use `allow` to specify which dependencies to maintain

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    allow:
      # Allow updates for Lodash
      - dependency-name: "lodash"
      # Allow updates for React and any packages starting "react"
      - dependency-name: "react*"

  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"
    allow:
      # Allow both direct and indirect updates for all packages
      - dependency-type: "all"

  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    allow:
      # Allow only direct updates for
      # Django and any packages starting "django"
      - dependency-name: "django*"
        dependency-type: "direct"
      # Allow only production updates for Sphinx
      - dependency-name: "sphinx"
        dependency-type: "production"

assignees

Verwende assignees zum Angeben einzelner zugewiesener Personen für alle Pull Requests, die für einen Paket-Manager ausgelöst wurden.

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.

# Specify assignees for pull requests

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # Add assignees
    assignees:
      - "octocat"

commit-message

Standardmäßig wird von Dependabot versucht, deine Commitnachrichteneinstellungen zu erkennen und ähnliche Muster zu verwenden. Verwende die Option commit-message, um deine Einstellungen explizit anzugeben.

Unterstützte Optionen

• prefix gibt ein Präfix für alle Commitnachrichten an. Wenn du ein Präfix für Commitnachrichten angibst, fügt GitHub automatisch einen Doppelpunkt zwischen dem definierten Präfix und der Commitnachricht hinzu, sofern das definierte Präfix mit einem Buchstaben, einer Zahl, einer schließenden Klammer oder einer eckigen Klammer rechts endet. Dies bedeutet, dass beispielsweise kein Doppelpunkt zwischen dem Präfix und der Commitnachricht hinzugefügt wird, wenn du das Präfix mit einem Leerzeichen beendest. Das folgende Codeschnipsel enthält Beispiele für beide Versionen in derselben Konfigurationsdatei.

• prefix-development gibt ein separates Präfix für alle Commitnachrichten an, durch die Abhängigkeiten in der Entwicklungsabhängigkeitsgruppe aktualisiert werden. Wenn du einen Wert für diese Option angibst, wird prefix nur für Updates von Abhängigkeiten in der Produktionsabhängigkeitsgruppe verwendet. Dies wird unterstützt von: bundler, composer, mix, maven, npm und pip.

• include: "scope" gibt an, dass jedem Präfix eine Liste der Abhängigkeiten folgt, die im Commit aktualisiert wurden.

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.

# 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"
      include: "scope"

Wenn du die gleiche Konfiguration wie im obigen Beispiel verwendest, generiert ein bump-Vorgang der requests-Bibliothek in der pip-Entwicklungsabhängigkeitsgruppe die folgende Commitnachricht:

pip dev: bump requests from 1.0.0 to 1.0.1

ignore

Standardmäßig werden alle Abhängigkeiten von Dependabot auf dem neuesten Stand gehalten, die explizit in einem Manifest definiert sind. Darüber hinaus aktualisieren Dependabot-Sicherheitsupdates auch anfällige Abhängigkeiten, die in Sperrdateien definiert sind. Du kannst allow und ignore verwenden, um anzupassen, welche Abhängigkeiten aktuell gehalten werden sollen. Dependabot sucht nach allen zulässigen Abhängigkeiten und filtert dann alle ignorierten Abhängigkeiten oder Versionen aus. Eine Abhängigkeit, die sowohl mit einer als auch einer allow und einer ignore übereinstimmt, wird ignoriert.

Abhängigkeiten können entweder ignoriert werden, indem sie zu ignore hinzugefügt werden oder indem der Befehl @dependabot ignore für einen Pull Request verwendet wird, der von Dependabot geöffnet wurde.

Erstellen von ignore-Bedingungen aus @dependabot ignore

Abhängigkeiten, die mithilfe des Befehls @dependabot ignore ignoriert werden, werden für jeden Paket-Manager zentral gespeichert. Wenn du mit dem Ignorieren von Abhängigkeiten in der Datei dependabot.yml beginnst, werden diese vorhandenen Einstellungen neben den ignore-Abhängigkeiten in der Konfiguration berücksichtigt.

Du kannst überprüfen, ob ignore-Einstellungen von einem Repository gespeichert wurden, indem du das Repository nach "@dependabot ignore" in:comments durchsuchst. Wenn du eine auf diese Weise ignorierte Abhängigkeit nicht mehr ignorieren möchtest, öffne den Pull Request erneut.

Weitere Informationen zum Befehl @dependabot ignore findest du unter Verwalten von Pull Requests für Abhängigkeitsupdates.

Angeben von zu ignorierenden Abhängigkeiten und Versionen

Du kannst die Option ignore verwenden, um anzupassen, welche Abhängigkeiten aktualisiert werden. Die Aktion ignore unterstützt die folgenden Optionen:

• dependency-name: Verwende diese Option, um Updates für Abhängigkeiten mit übereinstimmenden Namen zu ignorieren. Verwende optional * für die Übereinstimmung mit null oder mehr Zeichen. Für Java-Abhängigkeiten lautet das Format des dependency-name-Attributs: groupId:artifactId (zum Beispiel: org.kohsuke:github-api). Um zu verhindern, dass Dependabot die TypeScript-Typdefinitionen von DefinitelyTyped automatisch aktualisiert, verwende @types/*.
• versions: Verwende diese Option, um bestimmte Versionen oder Bereiche von Versionen zu ignorieren. Wenn du einen Bereich definieren möchtest, verwende das Standardmuster für den Paket-Manager. Verwende z. B. für npm ^1.0.0, für Bundler ~> 2.0, für Docker die Ruby-Versionssyntax und für NuGet 7.*.
• update-types: Verwende diese Option zum Ignorieren von Arten von Updates, z. B. bei semantischer Versionierung (SemVer) major-, minor- oder patch-Updates für Versionsupdates (Beispiel: Mit version-update:semver-patch werden Patchupdates ignoriert). Du kannst diese Option mit dependency-name: "*" kombinieren, um bestimmte update-types für alle Abhängigkeiten zu ignorieren. Derzeit sind version-update:semver-major, version-update:semver-minor und version-update:semver-patch die einzigen unterstützten Optionen. Sicherheitsupdates sind von dieser Einstellung nicht betroffen.

Wenn versions und update-types zusammen verwendet werden, werden von Dependabot Updates in jedem der Sätze ignoriert.

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.

# Use `ignore` to specify dependencies that should not be updated

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    ignore:
      - dependency-name: "express"
        # For Express, ignore all updates for version 4 and 5
        versions: ["4.x", "5.x"]
        # For Lodash, ignore all updates
      - dependency-name: "lodash"
        # For AWS SDK, ignore all patch updates
      - dependency-name: "aws-sdk"
        update-types: ["version-update:semver-patch"]

insecure-external-code-execution

Paket-Manager mit den package-ecosystem-Werten bundler, mix und pip können externen Code im Manifest als Teil des Versionsupdateprozesses ausführen. Dadurch kann ein kompromittiertes Paket möglicherweise Anmeldeinformationen stehlen oder Zugriff auf konfigurierte Registrierungen erhalten. Wenn du eine registries-Einstellung in einer updates-Konfiguration hinzufügst, wird von Dependabot die Ausführung von externem Code automatisch verhindert. In diesem Fall kann das Versionsupdate fehlschlagen. Du kannst dieses Verhalten außer Kraft setzen und die Ausführung von externem Code für bundler-, mix- und pip-Paket-Manager zulassen, indem du insecure-external-code-execution auf allow festlegst.

Du kannst die Ausführung von externem Code explizit ablehnen, unabhängig davon, ob es eine registries-Einstellung für diese Updatekonfiguration gibt, indem du insecure-external-code-execution auf deny festlegst.

# Allow external code execution when updating dependencies from private registries

version: 2
registries:
  ruby-github:
    type: rubygems-server
    url: https://rubygems.pkg.github.com/octocat/github_api
    token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
updates:
  - package-ecosystem: "bundler"
    directory: "/rubygems-server"
    insecure-external-code-execution: allow
    registries: "*"
    schedule:
      interval: "monthly"

labels

Standardmäßig löst Dependabot alle Pull Requests mit der Bezeichnung dependencies aus. Wenn mehrere Paket-Manager definiert sind, enthält Dependabot eine zusätzliche Bezeichnung für jeden Pull Request. Dies gibt an, welche Sprache oder welches Ökosystem die Pull Request aktualisiert, z. B. java für Gradle-Updates und submodules für Git-Untermodul-Updates. Dependabot erstellt diese Standardbezeichnungen automatisch, sofern in Ihrem Repository erforderlich.

Verwende labels zum Außerkraftsetzen der Standardbezeichnungen, und gib alternative Bezeichnungen für alle Pull Requests an, die für einen Paket-Manager ausgelöst wurden. Wenn eine dieser Bezeichnungen im Repository nicht definiert ist, wird sie ignoriert. Verwende labels: [ ] zum Deaktivieren aller Bezeichnungen, einschließlich der Standardbezeichnungen.

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.

# Specify labels for pull requests

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # Specify labels for npm pull requests
    labels:
      - "npm"
      - "dependencies"

milestone

Verwende milestone zum Zuordnen aller Pull Requests, die für einen Paket-Manager mit einem Meilenstein ausgelöst wurden. Du musst den numerischen Bezeichner des Meilensteins und nicht seine Bezeichnung angeben. Wenn du einen Meilenstein anzeigst, ist der letzte Teil der Seiten-URL nach milestone der Bezeichner. Beispiel: https://github.com/<org>/<repo>/milestone/3.

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.

# Specify a milestone for pull requests

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

open-pull-requests-limit

Standardmäßig werden von Dependabot maximal fünf Pull Requests für Versionsupdates geöffnet. Sobald fünf offene Pull Requests von Dependabot vorliegen, werden neue Anforderungen erst dann von Dependabot geöffnet, wenn einige dieser geöffneten Anforderungen gemergt oder geschlossen werden. Verwende open-pull-requests-limit, um diesen Grenzwert zu ändern. Dies bietet auch eine einfache Möglichkeit, Versionsupdates für einen Paket-Manager vorübergehend zu deaktivieren.

Diese Option hat keine Auswirkungen auf Sicherheitsupdates, die einen separaten, internen Grenzwert von zehn offenen Pull Requests aufweisen.

# Specify the number of open pull requests allowed

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # Disable version updates for npm dependencies
    open-pull-requests-limit: 0

  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    # Allow up to 10 open pull requests for pip dependencies
    open-pull-requests-limit: 10

pull-request-branch-name.separator

Von Dependabot wird ein Branch für jeden Pull Request generiert. Jeder Branchname enthält dependabot und den Paket-Manager und die Abhängigkeit, der/die aktualisiert wird. Standardmäßig werden diese Teile jeweils durch das Symbol / getrennt, z. B.: dependabot/npm_and_yarn/next_js/acorn-6.4.1.

Verwende pull-request-branch-name.separator zum Angeben eines anderen Trennzeichens. Möglich sind hier die Zeichen "-", _ oder /. Das Bindestrichsymbol muss zwischen Anführungszeichen gesetzt werden, da es andernfalls als Start einer leeren YAML-Liste interpretiert wird.

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.

# Specify a different separator for branch names

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    pull-request-branch-name:
      # Separate sections of the branch name with a hyphen
      # for example, `dependabot-npm_and_yarn-next_js-acorn-6.4.1`
      separator: "-"

rebase-strategy

Standardmäßig wird von Dependabot automatisch ein Rebase von offenen Pull Requests ausgeführt, wenn Änderungen an dem jeweiligen Pull Request erkannt werden. Verwende rebase-strategy, um dieses Verhalten zu deaktivieren.

Verfügbare Rebase-Strategien

• auto zum Verwenden des Standardverhaltens und zur Rebase-Ausführung, wenn Änderungen erkannt werden.
• disabled zum Deaktivieren von automatischem Rebasing.

Wenn rebase-strategy auf auto festgelegt ist, versucht Dependabot in den folgenden Fällen, ein Rebase für Pull Requests auszuführen.

• Wenn du Dependabot version updates verwendest, für jeden geöffneten Dependabot-Pull Request bei der Ausführung deines Zeitplans.
• Wenn du einen geschlossenen Dependabot-Pull Request erneut öffnest.
• Wenn du den Wert von target-branch in der Dependabot-Konfigurationsdatei änderst. Weitere Informationen zu diesem Feld findest du unter target-branch.
• Wenn Dependabot erkennt, dass ein Dependabot-Pull Request nach einem kürzlichen Pushvorgang in den Zielbranch in Konflikt steht.

Wenn rebase-strategy auf disabled festgelegt ist, beendet Dependabot das Rebasing für Pull Requests.

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.

# Disable automatic rebasing

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # Disable rebasing for npm pull requests
    rebase-strategy: "disabled"

registries

Damit Dependabot beim Ausführen eines Versionsupdates auf eine private Paketregistrierung zugreifen darf, musst du eine registries-Einstellung in die relevante updates-Konfiguration aufnehmen. Du kannst die Verwendung aller definierten Registrierungen zulassen, indem du registries auf "*" festlegst. Alternativ dazu kannst du die Registrierungen auflisten, die vom Update verwendet werden können. Verwende dazu den Namen der Registrierung, wie im registries-Abschnitt der obersten Ebene der Datei dependabot.yml definiert. Weitere Informationen findest du nachstehend unter Konfigurationsoptionen für private Registrierungen.

Wenn du zulassen möchtest, dass von Dependabot bundler-, mix- und pip-Paket-Manager zum Aktualisieren von Abhängigkeiten in privaten Registrierungen verwendet werden können, hast du die Möglichkeit, die Ausführung von externem Code zuzulassen. Weitere Informationen findest du im obigen Abschnitt insecure-external-code-execution.

# Allow Dependabot to use one of the two defined private registries
# when updating dependency versions for this ecosystem

version: 2
registries:
  maven-github:
    type: maven-repository
    url: https://maven.pkg.github.com/octocat
    username: octocat
    password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}
  npm-npmjs:
    type: npm-registry
    url: https://registry.npmjs.org
    username: octocat
    password: ${{secrets.MY_NPM_PASSWORD}}
updates:
  - package-ecosystem: "gitsubmodule"
    directory: "/"
    registries:
      - maven-github
    schedule:
      interval: "monthly"

reviewers

Verwende reviewers zum Angeben von einzelnen Reviewern oder Teams von Reviewern für alle Pull Requests, die für einen Paket-Manager ausgelöst wurden. Du musst den vollständigen Teamnamen verwenden, einschließlich der Organisation, wie bei der Aktion „@mentioning“.

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.

# Specify reviewers for pull requests

version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    # Add reviewers
    reviewers:
      - "octocat"
      - "my-username"
      - "my-org/python-team"

schedule.day

Wenn du einen Updatezeitplan vom Typ weekly festlegst, wird von Dependabot standardmäßig am Montag zu einem zufälligen Zeitpunkt eine Prüfung auf neue Versionen für das Repository durchgeführt. Verwende schedule.day, um einen alternativen Tag für die Prüfung auf Updates anzugeben.

Unterstützte Werte

• monday
• tuesday
• wednesday
• thursday
• friday
• saturday
• sunday

# Specify the day for weekly checks

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      # Check for npm updates on Sundays
      day: "sunday"

schedule.time

Standardmäßig wird von Dependabot zu einem zufälligen Zeitpunkt eine Prüfung auf neue Versionen für das Repository durchgeführt. Verwende schedule.time, um eine alternative Tageszeit für die Prüfung auf Updates (Format: hh:mm) anzugeben.

# Set a time for checks
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      # Check for npm updates at 9am UTC
      time: "09:00"

schedule.timezone

Standardmäßig wird von Dependabot zu einem zufälligen Zeitpunkt eine Prüfung auf neue Versionen für das Repository durchgeführt. Verwende schedule.timezone, um eine alternative Zeitzone anzugeben. Der Bezeichner der Zeitzone muss aus der von iana verwalteten Zeitzonendatenbank stammen. Weitere Informationen findest du in der Liste der Zeitzonen aus der Zeitzonen-Datenbank (tz database).

# Specify the timezone for checks

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      time: "09:00"
      # Use Japan Standard Time (UTC +09:00)
      timezone: "Asia/Tokyo"

target-branch

Standardmäßig wird von Dependabot eine Prüfung auf Manifestdateien im Standardbranch durchgeführt. Zudem werden Pull Requests für Versionsupdates für diesen Branch ausgelöst. Verwende target-branch, um einen anderen Branch für Manifestdateien und für Pull Requests anzugeben. Wenn du diese Option verwendest, wirken sich die Einstellungen für diesen Paket-Manager nicht mehr auf Pull Requests aus, die für Sicherheitsupdates ausgelöst werden.

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

vendor

Verwende die Option vendor, um Dependabot anzuweisen, ein Vendoring der Abhängigkeiten durchzuführen, wenn die Abhängigkeiten aktualisiert werden. Verwende diese Option nicht, wenn du gomod verwendest, da Dependabot Vendoring für dieses Tool automatisch erkennt.

# Configure version updates for both dependencies defined in manifests and vendored dependencies

version: 2
updates:
  - package-ecosystem: "bundler"
    # Raise pull requests to update vendored dependencies that are checked in to the repository
    vendor: true
    directory: "/"
    schedule:
      interval: "weekly"

Von Dependabot werden nur die anbieterbezogenen Abhängigkeiten aktualisiert, die sich in bestimmten Verzeichnissen in einem Repository befinden.

Paket-Manager	Erforderlicher Dateipfad für anbieterbezogene Abhängigkeiten	Weitere Informationen
bundler	Die Abhängigkeiten müssen sich im vendor/cache-Verzeichnis befinden. Andere Dateipfade werden nicht unterstützt.	Dokumentation zu bundle cache
gomod	Keine Pfadanforderung (Abhängigkeiten befinden sich in der Regel im vendor-Verzeichnis)	Dokumentation zu go mod vendor

versioning-strategy

Wenn von Dependabot für ein Versionsupdate eine Manifestdatei bearbeitet wird, werden die folgenden allgemeinen Strategien eingesetzt:

• Für Apps werden die Versionsanforderungen erhöht, z. B. npm, pip und Composer.
• Für Bibliotheken wird der Bereich der Versionen erweitert, z. B. Bundler und Cargo.

Verwende die Option versioning-strategy, um dieses Verhalten für unterstützte Paket-Manager zu ändern.

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.

Verfügbare Updatestrategien

Option	Unterstützt von	Aktion
lockfile-only	bundler, cargo, composer, mix, npm, pip	Erstelle nur Pull Requests zum Aktualisieren von Sperrdateien. Ignoriere alle neuen Versionen, die Paketmanifeständerungen erfordern würden.
auto	bundler, cargo, composer, mix, npm, pip	Folge der oben beschriebenen Standardstrategie.
widen	composer, npm	Lockere, wenn möglich, die Versionsanforderungen so, dass sowohl die neue als auch die alte Version einbezogen wird.
increase	bundler, composer, npm und pip	Erhöhe die Versionsanforderung immer so, dass sie der neuen Version entspricht.
increase-if-necessary	bundler, composer, npm und pip	Erhöhe die Versionsanforderung nur, wenn dies für die neue Version erforderlich ist.

# Customize the manifest version strategy

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # Update the npm manifest file to relax
    # the version requirements
    versioning-strategy: widen

  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"
    # Increase the version requirements for Composer
    # only when required
    versioning-strategy: increase-if-necessary

  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    # Only allow updates to the lockfile for pip and
    # ignore any version updates that affect the manifest
    versioning-strategy: lockfile-only

Konfigurationsoptionen für private Registrierungen

Der registries-Schlüssel der obersten Ebene ist optional. Damit kannst du Authentifizierungsdetails angeben, die von Dependabot dazu verwendet werden können, auf private Paketregistrierungen zuzugreifen.

Der Wert des registries-Schlüssels ist ein assoziatives Array. Jedes Element dieses Arrays besteht aus einem Schlüssel, der eine bestimmte Registrierung und einen Wert identifiziert, der ein assoziatives Array darstellt, das die Einstellungen angibt, die für den Zugriff auf diese Registrierung erforderlich sind. Durch die folgende dependabot.yml-Datei wird eine Registrierung konfiguriert, die im Abschnitt registries der Datei als dockerhub identifiziert wird. Anschließend wird im Abschnitt updates der Datei darauf verwiesen.

# Minimal settings to update dependencies 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"

Du verwendest die folgenden Optionen, um Zugriffseinstellungen anzugeben. Registrierungseinstellungen müssen einen type und eine url enthalten, sowie in der Regel eine Kombination aus username und password oder ein token.

Option	BESCHREIBUNG
type	Identifiziert den Typ der Registrierung. Nachstehend findest du die vollständige Liste der Typen.
url	Die URL, die für den Zugriff auf die Abhängigkeiten in dieser Registrierung verwendet werden soll. Das Protokoll ist optional. Falls nicht angegeben, https:// wird angenommen. Nachstehende Schrägstriche werden von Dependabot nach Bedarf hinzugefügt oder ignoriert.
username	Der Benutzername, der von Dependabot für den Zugriff auf die Registrierung verwendet wird.
password	Ein Verweis auf einen geheimen Dependabot-Schlüssel, der das Kennwort für den angegebenen Benutzer enthält. Weitere Informationen findest du unter Konfigurieren des Zugriffs auf private Registrierungen für Dependabot.
key	Ein Verweis auf einen geheimen Dependabot-Schlüssel, der einen Zugriffsschlüssel für diese Registrierung enthält. Weitere Informationen findest du unter Konfigurieren des Zugriffs auf private Registrierungen für Dependabot.
token	Ein Verweis auf einen geheimen Dependabot-Schlüssel, der ein Zugriffstoken für diese Registrierung enthält. Weitere Informationen findest du unter Konfigurieren des Zugriffs auf private Registrierungen für Dependabot.
replaces-base	Bei Registrierungen löst Dependabot Abhängigkeiten mithilfe der angegebenen URL anstelle der Basis-URL des jeweiligen Ökosystems auf, wenn der boolesche Wert true lautet. Bei Registrierungen mit type: python-index werden Abhängigkeiten beim booleschen Wert true beispielsweise von pip mithilfe der angegebenen URL anstelle der Basis-URL des Python-Paketindex aufgelöst (Standardwert: https://pypi.org/simple).

Du musst die erforderlichen Einstellungen für jede von dir angegebene Konfiguration type angeben. Einige Typen lassen mehr als eine Möglichkeit zum Herstellen einer Verbindung zu. Die folgenden Abschnitte enthalten Details zu den Einstellungen, die für den jeweiligen type zu verwenden sind.

composer-repository

Vom Typ composer-repository werden Benutzername und Kennwort unterstützt.

registries:
  composer:
    type: composer-repository
    url: https://repo.packagist.com/example-company/
    username: octocat
    password: ${{secrets.MY_PACKAGIST_PASSWORD}}

docker-registry

Dependabot funktioniert mit allen Containerregistrierungen, die die OCI-Containerregistrierungsspezifikation implementieren. Weitere Informationen findest du unter https://github.com/opencontainers/distribution-spec/blob/main/spec.md. Dependabot unterstützt die Authentifizierung bei privaten Registrierungen über einen zentralen Tokendienst oder die HTTP-Standardauthentifizierung. Weitere Informationen findest du unter Tokenauthentifizierungsspezifikation in der Docker-Dokumentation und unter Standardauthentifizierung in Wikipedia.

Vom Typ docker-registry werden Benutzername und Kennwort unterstützt.

registries:
  dockerhub:
    type: docker-registry
    url: https://registry.hub.docker.com
    username: octocat
    password: ${{secrets.MY_DOCKERHUB_PASSWORD}}
    replaces-base: true

Der Typ docker-registry kann auch zum Pullen aus einer privaten Amazon ECR-Instanz mithilfe statischer AWS-Anmeldeinformationen verwendet werden.

registries:
  ecr-docker:
    type: docker-registry
    url: https://1234567890.dkr.ecr.us-east-1.amazonaws.com
    username: ${{secrets.ECR_AWS_ACCESS_KEY_ID}}
    password: ${{secrets.ECR_AWS_SECRET_ACCESS_KEY}}
    replaces-base: true

git

Vom Typ git werden Benutzername und Kennwort unterstützt.

registries:
  github-octocat:
    type: git
    url: https://github.com
    username: x-access-token
    password: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}

hex-organization

Vom Typ hex-organization werden Organisation und Schlüssel unterstützt.

registries:
  github-hex-org:
    type: hex-organization
    organization: github
    key: ${{secrets.MY_HEX_ORGANIZATION_KEY}}

hex-repository

Der Typ hex-repository unterstützt einen Authentifizierungsschlüssel.

repo ist ein Pflichtfeld, das mit dem Namen des Repositorys übereinstimmen muss, der in der Abhängigkeitsdeklaration verwendet wird.

public-key-fingerprint ist ein optionales Konfigurationsfeld, das den Fingerabdruck des öffentlichen Schlüssels für das Hex-Repository darstellt. public-key-fingerprint wird von Hex verwendet, um eine Vertrauensstellung mit dem privaten Repository herzustellen. Das Feld public-key-fingerprint kann entweder als Klartext aufgeführt oder als Dependabot-Geheimnis gespeichert werden.

registries:
   github-hex-repository:
     type: hex-repository
     repo: private-repo
     url: https://private-repo.example.com
     auth-key: ${{secrets.MY_AUTH_KEY}}
     public-key-fingerprint: ${{secrets.MY_PUBLIC_KEY_FINGERPRINT}}

maven-repository

Vom Typ maven-repository werden Benutzername und Kennwort unterstützt.

registries:
  maven-artifactory:
    type: maven-repository
    url: https://artifactory.example.com
    username: octocat
    password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}
    replaces-base: true

npm-registry

Vom Typ npm-registry werden Benutzername und Kennwort oder Token unterstützt.

Wenn du Benutzername und Kennwort verwendest, kann das Authentifizierungstoken von .npmrc ein base64-codiertes _password enthalten. Das Kennwort, auf das in der Dependabot-Konfigurationsdatei verwiesen wird, muss jedoch das ursprüngliche (nicht codierte) Kennwort sein.

registries:
  npm-npmjs:
    type: npm-registry
    url: https://registry.npmjs.org
    username: octocat
    password: ${{secrets.MY_NPM_PASSWORD}}  # Must be an unencoded password
    replaces-base: true

registries:
  npm-github:
    type: npm-registry
    url: https://npm.pkg.github.com
    token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
    replaces-base: true

Aus Sicherheitsgründen legt Dependabot keine Umgebungsvariablen fest. Yarn (v2 und höher) erfordert, dass alle Umgebungsvariablen festgelegt sind, auf die zugegriffen wird. Wenn du in deiner .yarnrc.yml-Datei auf Umgebungsvariablen zugreifst, solltest du einen Fallbackwert wie ${ENV_VAR-fallback} or ${ENV_VAR:-fallback} angeben. Weitere Informationen findest du unter Yarnrc-Dateien in der Yarn-Dokumentation.

nuget-feed

Vom Typ nuget-feed werden Benutzername und Kennwort oder Token unterstützt.

registries:
  nuget-example:
    type: nuget-feed
    url: https://nuget.example.com/v3/index.json
    username: octocat@example.com
    password: ${{secrets.MY_NUGET_PASSWORD}}

registries:
  nuget-azure-devops:
    type: nuget-feed
    url: https://pkgs.dev.azure.com/.../_packaging/My_Feed/nuget/v3/index.json
    username: octocat@example.com
    password: ${{secrets.MY_AZURE_DEVOPS_TOKEN}}

python-index

Vom Typ python-index werden Benutzername und Kennwort oder Token unterstützt.

registries:
  python-example:
    type: python-index
    url: https://example.com/_packaging/my-feed/pypi/example
    username: octocat
    password: ${{secrets.MY_BASIC_AUTH_PASSWORD}}
    replaces-base: true

registries:
  python-azure:
    type: python-index
    url: https://pkgs.dev.azure.com/octocat/_packaging/my-feed/pypi/example
    username: octocat@example.com
    password: ${{secrets.MY_AZURE_DEVOPS_TOKEN}}
    replaces-base: true

rubygems-server

Vom Typ rubygems-server werden Benutzername und Kennwort oder Token unterstützt.

registries:
  ruby-example:
    type: rubygems-server
    url: https://rubygems.example.com
    username: octocat@example.com
    password: ${{secrets.MY_RUBYGEMS_PASSWORD}}
    replaces-base: true

registries:
  ruby-github:
    type: rubygems-server
    url: https://rubygems.pkg.github.com/octocat/github_api
    token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
   replaces-base: true

terraform-registry

Vom Typ terraform-registry wird ein Token unterstützt.

registries:
  terraform-example:
    type: terraform-registry
    url: https://terraform.example.com
    token: ${{secrets.MY_TERRAFORM_API_TOKEN}}

Aktivieren der Unterstützung für Ökosysteme auf Betaebene

enable-beta-ecosystems

Standardmäßig werden von Dependabot die Abhängigkeitsmanifeste und Sperrdateien nur für vollständig unterstützte Ökosysteme aktualisiert. Verwende das Flag enable-beta-ecosystems, um Updates für Ökosysteme zu abonnieren, die noch nicht allgemein verfügbar sind.

# Configure beta ecosystem

version: 2
enable-beta-ecosystems: true
updates:
  - package-ecosystem: "beta-ecosystem"
    directory: "/"
    schedule:
      interval: "weekly"