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.

Diese Version von GitHub Enterprise wird eingestellt am 2023-03-15. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Automatisieren von Dependabot mit GitHub Actions

Beispiele für die Verwendung von GitHub Actions zum Automatisieren allgemeiner Dependabot-bezogener Aufgaben.

Who can use this feature

People with write permissions to a repository can configure GitHub Actions to respond to Dependabot-created pull requests.

**Hinweis:** Dependabot Sicherheits- und Versionsupdates befinden sich derzeit in der öffentlichen Beta und unterliegen Änderungen.

Hinweis: Dein Websiteadministrator muss Dependabot updates für your GitHub Enterprise Server instance einrichten, damit du dieses Feature verwenden kannst. Weitere Informationen findest du unter Aktivieren von Dependabot für dein Unternehmen.

Informationen zu Dependabot und GitHub Actions

Von Dependabot werden Pull Requests erstellt, damit die Abhängigkeiten auf dem aktuellen Stand gehalten werden. Außerdem kannst du GitHub Actions verwenden, um automatisierte Aufgaben auszuführen, wenn diese Pull Requests erstellt werden. Rufe beispielsweise zusätzliche Artefakte ab, füge Bezeichnungen hinzu, führe Tests aus, oder ändere den Pull Request anderweitig.

Reagieren auf Ereignisse

Von Dependabot können GitHub Actions-Workflows in den zugehörigen Pull Requests und Kommentaren ausgelöst werden. Bestimmte Ereignisse werden jedoch anders behandelt.

Für Workflows, die von Dependabot (github.actor == 'dependabot[bot]') mithilfe der Ereignisse pull_request, pull_request_review, pull_request_review_comment, push, create, deployment und deployment_status initiiert werden, gelten die folgenden Einschränkungen:

  • GITHUB_TOKEN verfügt standardmäßig über Schreibschutzberechtigungen.

  • Geheimnisse werden aus Dependabot-Geheimnissen gefüllt. GitHub Actions-Geheimnisse sind nicht verfügbar.

    Für Workflows, die von Dependabot (github.actor == 'dependabot[bot]') mithilfe des Ereignisses pull_request_target initiiert werden, ist das GITHUB_TOKEN schreibgeschützt, und Geheimnisse sind nicht verfügbar, wenn der Basisverweis des Pull Requests von Dependabot (github.actor == 'dependabot[bot]') erstellt wurde.

Weitere Informationen findest du unter Aufrechterhalten der Sicherheit von GitHub Actions und GitHub-Workflows: Verhindern von pwn-Anforderungen.

Ändern von GITHUB_TOKEN-Berechtigungen

Standardmäßig erhalten GitHub Actions-Workflows, die von Dependabot ausgelöst werden, ein GITHUB_TOKEN mit Schreibschutzberechtigungen. Du kannst den Schlüssel permissions in deinem Workflow verwenden, um den Zugriff für das Token zu erhöhen:

name: CI
on: pull_request

# Set the access for individual scopes, or use permissions: write-all
permissions:
  pull-requests: write
  issues: write
  repository-projects: write
  ...

jobs:
  ...

Weitere Informationen findest du unter Ändern der Berechtigungen für GITHUB_TOKEN.

Zugreifen auf Geheimnisse

Wenn von einem Dependabot-Ereignis ein Workflow ausgelöst wird, sind die einzigen für den Workflow verfügbaren Geheimnisse Dependabot-Geheimnisse. GitHub Actions-Geheimnisse sind nicht verfügbar. Daher musst du alle Geheimnisse, die von einem Workflow verwendet werden, der von Dependabot-Ereignissen ausgelöst wird, als Dependabot-Geheimnisse speichern. Weitere Informationen findest du unter Verwalten verschlüsselter Geheimnisse für Dependabot.

Dependabot-Geheimnisse werden dem secrets-Kontext hinzugefügt und mit exakt derselben Syntax wie Geheimnisse für GitHub Actions referenziert. Weitere Informationen findest du unter Verschlüsselte Geheimnisse.

Wenn du über einen Workflow verfügst, der von Dependabot und auch von anderen Akteuren ausgelöst wird, besteht die einfachste Lösung darin, das Token mit den erforderlichen Berechtigungen in einer Aktion und in einem Dependabot-Geheimnis mit identischen Namen zu speichern. Anschließend kann der Workflow einen einzelnen Aufruf dieser Geheimnisse enthalten. Wenn das Geheimnis für Dependabot einen anderen Namen aufweist, verwendest du Bedingungen, um die richtigen Geheimnisse für unterschiedliche Akteure anzugeben. Beispiele für die Verwendung von Bedingungen findest du unter Gängige Automatisierungen.

Für den mittels Benutzernamen und Kennwort erfolgenden Zugriff auf eine private Containerregistrierung in AWS muss ein Workflow ein Geheimnis für username und password enthalten. Wenn von Dependabot im nachstehenden Beispiel der Workflow ausgelöst wird, werden die Dependabot-Geheimnisse mit den Namen READONLY_AWS_ACCESS_KEY_ID und READONLY_AWS_ACCESS_KEY verwendet. Wenn ein anderer Akteur den Workflow auslöst, werden die Aktionsgeheimnisse mit diesen Namen verwendet.

name: CI
on:
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      - name: Login to private container registry for dependencies
        uses: docker/login-action@v1
        with:
          registry: https://1234567890.dkr.ecr.us-east-1.amazonaws.com
          username: ${{ secrets.READONLY_AWS_ACCESS_KEY_ID }}
          password: ${{ secrets.READONLY_AWS_ACCESS_KEY }}

      - name: Build the Docker image
        run: docker build . --file Dockerfile --tag my-image-name:$(date +%s)

Manuelles erneutes Ausführen eines Workflows

Du kannst einen fehlgeschlagenen Dependabot-Workflow auch manuell erneut ausführen. Der Workflow wird dann mit einem Lese-/Schreibtoken und Zugriff auf Geheimnisse ausgeführt. Bevor du einen fehlgeschlagenen Workflow manuell erneut ausführst, solltest du immer die aktualisierte Abhängigkeit überprüfen. So kannst du sicherzustellen, dass durch die Änderung kein böswilliges oder unbeabsichtigtes Verhalten eingeführt wird.

Gängige Dependabot-Automatisierungen

Nachstehend sind mehrere gängige Szenarios aufgeführt, in denen mithilfe von GitHub Actions eine Automatisierung durchgeführt werden kann.

Abrufen von Metadaten zu einem Pull Request

Eine große Anzahl von Automatisierungen erfordert Wissen über den Inhalt des Pull Requests: Du musst den Abhängigkeitsnamen kennen und wissen, ob es um eine Produktionsabhängigkeit geht und ob es sich um ein Haupt-, Neben- oder Patchupdate handelt.

Die Aktion dependabot/fetch-metadata macht all diese Informationen für dich verfügbar:

name: Dependabot fetch metadata
on: pull_request

permissions:
  pull-requests: write
  issues: write
  repository-projects: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: ${{ github.actor == 'dependabot[bot]' }}
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v1
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      # The following properties are now available:
      #  - steps.metadata.outputs.dependency-names
      #  - steps.metadata.outputs.dependency-type
      #  - steps.metadata.outputs.update-type      

Weitere Informationen findest du im dependabot/fetch-metadata-Repository.

Bezeichnen eines Pull Requests

Wenn du über andere Automatisierungs- oder Selektierungsworkflows verfügst, die auf GitHub-Bezeichnungen basieren, kannst du eine Aktion konfigurieren, um Bezeichnungen basierend auf den bereitgestellten Metadaten zuzuweisen.

Wenn du beispielsweise alle Produktionsabhängigkeitsaktualisierungen mit einer Bezeichnung kennzeichnen möchtest:

name: Dependabot auto-label
on: pull_request

permissions:
  pull-requests: write
  issues: write
  repository-projects: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: ${{ github.actor == 'dependabot[bot]' }}
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v1
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Add a label for all production dependencies
        if: ${{ steps.metadata.outputs.dependency-type == 'direct:production' }}
        run: gh pr edit "$PR_URL" --add-label "production"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}

Genehmigen eines Pull Requests

Wenn du Pull Requests von Dependabot automatisch genehmigen möchtest, kannst du die GitHub CLI in einem Workflow verwenden:

name: Dependabot auto-approve
on: pull_request

permissions:
  pull-requests: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: ${{ github.actor == 'dependabot[bot]' }}
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v1
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Approve a PR
        run: gh pr review --approve "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

Aktivieren der automatischen Zusammenführung für einen Pull Request

Wenn du Maintainern erlauben möchtest, bestimmte Pull Requests für automatisches Mergen zu markieren, kannst du die automatische Mergefunktion von GitHub nutzen. Dadurch kann der Pull Request zusammengeführt werden, wenn Tests und Genehmigungen der Regeln für den Schutz von Branches erfolgreich erfüllt werden. Weitere Informationen findest du unter Automatisches Zusammenführen eines Pull Requests und Verwalten einer Branchschutzregel.

Hinweis: Wenn du Statusüberprüfungen zum Testen von Pull Requests verwendest, solltest du Statusüberprüfungen müssen vor dem Zusammenführen bestanden werden für den Zielbranch für Pull Requests von Dependabot aktivieren. Diese Branchschutzregel stellt sicher, dass Pull Requests nicht zusammengeführt werden, es sei denn, alle erforderlichen Statusüberprüfungen sind erfolgreich. Weitere Informationen findest du unter Informationen zu Branchschutzregeln.

Du kannst stattdessen GitHub Actions und die GitHub CLI verwenden. Es folgt ein Beispiel, in dem alle Patchupdates automatisch in my-dependency gemergt werden:

name: Dependabot auto-merge
on: pull_request

permissions:
  contents: write
  pull-requests: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: ${{ github.actor == 'dependabot[bot]' }}
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v1
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Enable auto-merge for Dependabot PRs
        if: ${{contains(steps.metadata.outputs.dependency-names, 'my-dependency') && steps.metadata.outputs.update-type == 'version-update:semver-patch'}}
        run: gh pr merge --auto --merge "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

Problembehandlung bei fehlgeschlagenen Workflowausführungen

Überprüfe Folgendes, wenn die Workflowausführung fehlschlägt:

  • Du führst den Workflow nur aus, wenn er vom richtigen Akteur ausgelöst wird.
  • Du checkst den richtigen ref für den pull_request aus.
  • Die Geheimnisse sind in Dependabot-Geheimnissen und nicht als GitHub Actions-Geheimnisse verfügbar.
  • Du verfügst über ein GITHUB_TOKEN mit den richtigen Berechtigungen.

Informationen zum Schreiben und Debuggen von GitHub Actions findest du unter Informationen zu GitHub Actions.