Skip to main content

Enterprise Server 3.15 ist derzeit als Release Candidate verfügbar.

Automatisieren von Dependabot mit GitHub Actions

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

Wer kann dieses Feature verwenden?

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

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

Möglicherweise kannst du Dependabot updates nicht aktivieren oder deaktivieren, wenn eine Unternehmensbesitzerin eine Richtlinie auf Unternehmensebene festgelegt hat. Weitere Informationen findest du unter Erzwingen von Richtlinien für die Codesicherheit und -analyse für 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 über 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 nur über Leseberechtigungen.
  • Geheimnisse werden aus Dependabot-Geheimnissen aufgefü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 über Dependabot (github.event.pull_request.user.login == 'dependabot[bot]') erstellt wurde.

Diese Einschränkungen gelten auch dann, wenn der Workflow von einem anderen Akteur erneut ausgeführt wird.

Weitere Informationen sind unter „Aufrechterhalten der Sicherheit von GitHub Actions und GitHub-Workflows: Verhindern von pwn-Anforderungen“ zu finden.

Ä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 Automatische Tokenauthentifizierung.

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 Konfigurieren des Zugriffs auf private Registrierungen 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 Verwenden von Geheimnissen in GitHub-Aktionen.

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@v4

      - name: Login to private container registry for dependencies
        uses: docker/login-action@3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c
        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

Wenn du einen Dependabot-Workflow manuell erneut ausführst, wird er mit den gleichen Berechtigungen ausgeführt wie zuvor, auch wenn der/die Benutzer*in, von dem bzw. der die erneute Ausführung initiiert wurde, unterschiedliche Berechtigungen aufweist. Weitere Informationen findest du unter Erneutes Ausführen von Workflows und Jobs.

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.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d
        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.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d
        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.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d
        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}}
          GH_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 finden Sie unter Automatisches Zusammenführen eines Pull Requests und unter Verwalten einer Branchschutzregel.

Als Alternative zu Verzweigungsschutzregeln können Sie Regelsätze erstellen. Weitere Informationen findest du unter Informationen zu Regelsätzen.

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 Verwalten einer Branchschutzregel.

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.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d
        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}}
          GH_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 Schreiben von Workflows.