Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

Konfigurationsoptionen für die Datei dependabot.yml

Detaillierte Informationen über alle Optionen, mit denen du anpassen kannst, wie Dependabot deine Repositorys wartet.

Who can use this feature

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

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 entsprechendes Beispiel findest du unter Konfigurieren von Dependabot-Versionsupdates.

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 security updates.

Hinweis: Du kannst Dependabot alerts nicht mithilfe der Datei dependabot.yml konfigurieren.

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:

OptionErforderlichSicherheitsupdatesVersionsupdatesBESCHREIBUNG
package-ecosystemXXZu verwendender Paket-Manager
directoryXXSpeicherort von Paketmanifesten
schedule.intervalXXHäufigkeit der Suche nach Updates
allowXXAnpassen der zulässigen Updates
assigneesXXFür Pull Requests festzulegende zugewiesene Personen
commit-messageXXCommitnachrichteneinstellungen
enable-beta-ecosystemsXAktivieren von Ökosystemen mit Unterstützung auf Betaebene
ignoreXXIgnorieren bestimmter Abhängigkeiten oder Versionen
insecure-external-code-executionXZulassen oder Ablehnen der Codeausführung in Manifestdateien
labelsXXFür Pull Requests festzulegende Bezeichnungen
milestoneXXFür Pull Requests festzulegende Meilensteine
open-pull-requests-limitXXBeschränken der Anzahl der geöffneten Pull Requests für Versionsupdates
pull-request-branch-name.separatorXXÄndern des Trennzeichens für Branchnamen von Pull Requests
rebase-strategyXXDeaktivieren des automatischen Rebasing
registriesXPrivate Registrierungen, auf die Dependabot zugreifen kann
reviewersXXFür Pull Requests festzulegende Reviewer
schedule.dayXWochentag für die Suche nach Updates
schedule.timeXTageszeit für die Suche nach Updates (hh:mm)
schedule.timezoneXZeitzone für Tageszeit (Zonenbezeichner)
target-branchXBranch, für den Pull Requests erstellt werden sollen
vendorXAktualisieren von anbieterbezogenen oder zwischengespeicherten Abhängigkeiten
versioning-strategyXXVorgehensweise für die Aktualisierung von Manifestversionsanforderungen

Diese Optionen lassen sich grob in die folgenden Kategorien einteilen.

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.

Hinweis: Einige dieser Konfigurationsoptionen wirken sich möglicherweise auch auf Pull Requests aus, die für Sicherheitsupdates angreifbarer Paketmanifeste ausgelöst werden.

Sicherheitsupdates werden nur für angreifbare Paketmanifeste im Standardbranch ausgelöst. Wenn Konfigurationsoptionen für denselben Branch festgelegt werden („true“, es sei denn, du verwendest target-branch) und package-ecosystem sowie directory für das angreifbare Manifest angegeben wird, dann werden von Pull Requests für Sicherheitsupdates relevante Optionen verwendet.

Im Allgemeinen werden von Sicherheitsupdates alle Konfigurationsoptionen verwendet, die sich auf Pull Requests auswirken, z. B. das Hinzufügen von Metadaten oder das Ändern des Verhaltens. Weitere Informationen zu Sicherheitsupdates findest du unter Konfigurieren von Dependabot security updates.

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 nachstehend 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-ManagerYAML-WertUnterstützte VersionenPrivate RepositorysPrivate RegistrierungenVendoring
Bundlerbundlerv1, v2
Cargocargov1
Composercomposerv1, v2
Docker [1]dockerv1
Hexmixv1
elm-packageelmv0.19
Git-SubmodulgitsubmoduleKeine Angabe (Keine Version)
GitHub Actions [2]github-actionsKeine Angabe (Keine Version)
Go-Modulegomodv1
Gradle [3]gradleKeine Angabe (Keine Version)
Maven [4]mavenKeine Angabe (Keine Version)
npmnpmv6, v7, v8
NuGetnuget<= 4.8[5]
pip[6]pipv21.1.2
pipenvpip<= 2021-05-29
pip-compile[6]pip6.1.0
Poetrypipv1
pub [7]pubV2
Terraformterraform>= 0.13, <= 1.3.x
yarnnpmv1, v2, v3[8]

Tipp: Für Paket-Manager wie pipenv und poetry musst du den YAML-Wert pip verwenden. Wenn du deine Python-Abhängigkeiten z. B. mit poetry verwaltest und mit Dependabot deine Abhängigkeitsmanifestdatei für neue Versionen überwachen möchtest, nutze package-ecosystem: "pip" in deiner dependabot.yml-Datei.

[1] 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 der Datei dependabot.yml 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“.

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

[3] Dependabot führt Gradle nicht aus, unterstützt jedoch Updates an den folgenden Dateien: build.gradle, build.gradle.kts (für Kotlin-Projekte) sowie den über die apply-Deklaration eingeschlossenen Dateien, 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.

[4] Dependabot führt Maven nicht aus, unterstützt jedoch Updates an pom.xml-Dateien.

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

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

[7] 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.

[8] Dependabot unterstützt anbieterbezogene Abhä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.

IntervalltypenHäufigkeit
dailyWird an jedem Wochentag von Montag bis Freitag ausgeführt.
weeklyWird einmal jede Woche ausgeführt. Standardmäßig erfolgt die Ausführung am Montag. Verwende schedule.day, um die Standardeinstellung zu ändern.
monthlyWird 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"

Hinweis: Durch schedule wird definiert, wann von Dependabot ein neues Update versucht wird. Dies ist jedoch nicht der einzige Zeitpunkt, zu dem du Pull Requests erhalten kannst. Updates können basierend auf Änderungen an der dependabot.yml-Datei, Änderungen an den Manifestdateien nach einem fehlgeschlagenen Update oder basierend auf Dependabot security updates ausgelöst werden. Weitere Informationen findest du unter Häufigkeit von Dependabot-Pull Requests und Informationen zu Dependabot security updates.

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ängigkeitstypenUnterstützt von Paket-ManagernZulassen von Updates
    directAlleAlle explizit definierten Abhängigkeiten.
    indirectbundler, pip, composer, cargo und gomodAbhängigkeiten von direkten Abhängigkeiten (auch als Unterabhängigkeiten oder vorübergehende Abhängigkeiten bezeichnet).
    allAllAlle explizit definierten Abhängigkeiten. Für bundler, pip, composer, cargo und gomod auch die Abhängigkeiten von direkten Abhängigkeiten.
    productionbundler, composer, mix, maven, npm, pipNur Abhängigkeiten in der „Produktionsabhängigkeitsgruppe“.
    developmentbundler, composer, mix, maven, npm, pipNur 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

Hinweis: Die Optionen prefix und prefix-development verfügen über eine Begrenzung von 50 Zeichen.

  • 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 zu den @dependabot ignore-Befehlen 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 (z. B. ^1.0.0 für npm oder ~> 2.0 für Bundler).
  • 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"]

Hinweis: Von Dependabot können nur Versionsupdates für Manifest- oder Sperrdateien ausgeführt werden, wenn Dependabot auf alle Abhängigkeiten in der Datei zugreifen kann. Dies gilt auch dann, wenn du der ignore-Option deiner Konfigurationsdatei nicht zugängliche Abhängigkeiten hinzufügst. Weitere Informationen findest du unter Verwalten von Sicherheits- und Analyseeinstellungen für deine Organisation und Problembehandlung bei Dependabot-Fehlern.

Hinweis: Für das pub-Ökosystem wird von Dependabot kein Update ausgeführt, wenn die Version, für die Dependabot ein Update durchzuführen versucht, ignoriert wird. Dies gilt auch dann, wenn eine frühere Version verfügbar ist.

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.

Hinweis: Dependabot führt unbegrenzt ein Rebase für einen Pull Request aus, bis der Pull Request geschlossen oder zusammengeführt wird oder du Dependabot updates deaktivierst.

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

Hinweis: Dieses Verhalten gilt nur für Pull Requests, die in Konflikt mit dem Zielbranch stehen. Dependabot führt weiterhin ein Rebase für Pull Requests, die vor der Änderung der rebase-strategy-Einstellung geöffnet wurden, und Pull Requests, die Teil einer geplanten Ausführung sind, aus.

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-ManagerErforderlicher Dateipfad für anbieterbezogene AbhängigkeitenWeitere Informationen
bundlerDie Abhängigkeiten müssen sich im vendor/cache-Verzeichnis befinden.
Andere Dateipfade werden nicht unterstützt.
Dokumentation zu bundle cache
gomodKeine 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

OptionUnterstützt vonAktion
lockfile-onlybundler, cargo, composer, mix, npm, pipErstelle nur Pull Requests zum Aktualisieren von Sperrdateien. Ignoriere alle neuen Versionen, die Paketmanifeständerungen erfordern würden.
autobundler, cargo, composer, mix, npm, pipFolge der oben beschriebenen Standardstrategie.
widencomposer, npmLockere, wenn möglich, die Versionsanforderungen so, dass sowohl die neue als auch die alte Version einbezogen wird.
increasebundler, composer, npm und pipErhöhe die Versionsanforderung immer so, dass sie der neuen Version entspricht.
increase-if-necessarybundler, composer, npm und pipErhö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.

Hinweis: Private Registrierungen hinter Firewalls in privaten Netzwerken werden nicht unterstützt.

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
typeIdentifiziert den Typ der Registrierung. Nachstehend findest du die vollständige Liste der Typen.
urlDie 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.
usernameDer Benutzername, der von Dependabot für den Zugriff auf die Registrierung verwendet wird.
passwordEin Verweis auf einen geheimen Dependabot-Schlüssel, der das Kennwort für den angegebenen Benutzer enthält. Weitere Informationen findest du unter Verwalten verschlüsselter Geheimnisse für Dependabot.
keyEin Verweis auf einen geheimen Dependabot-Schlüssel, der einen Zugriffsschlüssel für diese Registrierung enthält. Weitere Informationen findest du unter Verwalten verschlüsselter Geheimnisse für Dependabot.
tokenEin Verweis auf einen geheimen Dependabot-Schlüssel, der ein Zugriffstoken für diese Registrierung enthält. Weitere Informationen findest du unter Verwalten verschlüsselter Geheimnisse für Dependabot.
replaces-baseBei 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).

Jeder Konfigurations-type erfordert, dass du bestimmte Einstellungen bereitstellst. 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"