Problembehandlung bei Fehlern, wenn Dependabot vorhandene Workflows auslöst
Nachdem du Dependabot für Ihre GitHub Enterprise Server-Instance eingerichtet hast, können Fehler angezeigt werden, wenn bestehende Workflows durch Dependabot-Ereignisse ausgelöst werden.
Standardmäßig werden Ausführungen von GitHub Actions-Workflows, die von Dependabot aufgrund von push-, pull_request-, pull_request_review- oder pull_request_review_comment-Ereignissen ausgelöst wurden, so behandelt, als wären sie in einem Repositoryfork geöffnet worden. Im Gegensatz zu Workflows, die von anderen Akteuren ausgelöst werden, erhalten sie ein schreibgeschütztes GitHub-Token (GITHUB_TOKEN) und verfügen nicht über Zugriff auf Geheimnisse, die normalerweise verfügbar sind. Dies führt dazu, dass alle Workflows, die versuchen, in das Repository zu schreiben, fehlschlagen, wenn sie von Dependabot ausgelöst wurden.
Es gibt drei Möglichkeiten, dieses Problem zu beheben:
- Du kannst deine Workflows mit einem Ausdruck wie
if: github.actor != 'dependabot[bot]'so aktualisieren, dass sie nicht mehr durch Dependabot ausgelöst werden. Weitere Informationen finden Sie unter Auswerten von Ausdrücken in Workflows und Aktionen. - Du kannst deine Workflows so ändern, dass sie einen zweistufigen Prozess mit
pull_request_targetverwenden, das nicht diesen Einschränkungen unterliegt. Weitere Informationen finden Sie unter Fehlerbehebung für Dependabot in GitHub Actions. - Du kannst Workflows bereitstellen, die durch den Dependabot-Zugriff auf Geheimnisse ausgelöst werden, und es dem Term
permissionserlauben, den Standardbereich vonGITHUB_TOKENzu erhöhen.
In diesem Artikel werden Hinweise zur Problembehandlung bereitgestellt. Weitere Informationen finden Sie unter Workflowsyntax für GitHub Actions.
Zugreifen auf Geheimnisse
Wenn ein Dependabot Ereignis einen Workflow auslöst, sind die einzigen Secrets, die dem Workflow zur Verfügung stehen, Dependabot Secrets. GitHub Actions Geheime Schlüssel sind nicht verfügbar. Sie müssen daher alle Secrets, die von einem durch Dependabot-Ereignisse ausgelösten Workflow verwendet werden, als Dependabot-Secrets 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 genau derselben Syntax wie Geheimnisse für GitHub Actions referenziert. Weitere Informationen findest du unter Verwenden von Geheimnissen in GitHub-Aktionen.
Wenn Sie über einen Workflow verfügen, der von Dependabot und auch von anderen Akteuren ausgelöst wird, besteht die einfachste Lösung darin, das Token mit den in einer Aktion erforderlichen Berechtigungen und in einem Dependabot Geheimschlüssel mit identischen Namen zu speichern. Anschließend kann der Workflow einen einzelnen Aufruf dieser Geheimnisse enthalten. Wenn das Secret für Dependabot einen anderen Namen hat, verwenden Sie Bedingungen, um festzulegen, welche Secrets von verschiedenen Akteuren verwendet werden sollen.
Beispiele für die Verwendung von Bedingungen finden Sie unter Automatisieren von Dependabot mit GitHub Actions.
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.
In diesem Beispiel werden, wenn Dependabot den Workflow auslöst, die Dependabot Secrets 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.
# Dieser Workflow verwendet Aktionen, die nicht von GitHub zertifiziert sind.
# Sie werden von einem Drittanbieter bereitgestellt und unterliegen
# separaten Nutzungsbedingungen, Datenschutzbestimmungen und Support
# Onlinedokumentation.
name: CI
on:
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v6
- 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)
# Dieser Workflow verwendet Aktionen, die nicht von GitHub zertifiziert sind.
# Sie werden von einem Drittanbieter bereitgestellt und unterliegen
# separaten Nutzungsbedingungen, Datenschutzbestimmungen und Support
# Onlinedokumentation.
name: CI
on:
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v6
- 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)
Ändern von GITHUB_TOKEN-Berechtigungen
Standardmäßig erhalten durch GitHub Actions ausgelöste Dependabot-Workflows ein GITHUB_TOKEN mit Nur-Lese-Berechtigungen. 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 ... jobs: ...
name: CI
on: pull_request
# Set the access for individual scopes, or use permissions: write-all
permissions:
pull-requests: write
issues: write
...
jobs:
...
Weitere Informationen findest du unter Verwenden von GITHUB_TOKEN für die Authentifizierung in Workflows.
Manuelles erneutes Ausführen eines Workflows
Wenn Sie einen Dependabot Workflow manuell erneut ausführen, wird er mit den gleichen Berechtigungen wie zuvor ausgeführt, auch wenn der Benutzer, der die erneute Ausführung initiiert hat, über unterschiedliche Berechtigungen verfügt. Weitere Informationen findest du unter Erneutes Ausführen von Workflows und Jobs.