Problembehandlung bei Fehlern, wenn Dependabot vorhandene Workflows auslöst
Nachdem Sie Updates für DependabotGitHub.com eingerichtet haben, kann es zu Fehlern kommen, wenn vorhandene Workflows durch Dependabot-Ereignisse ausgelöst werden.
Standardmäßig werden GitHub Actions Workflow-Ausführungen, die durch Dependabot von push, pull_request, pull_request_review oder pull_request_review_comment-Ereignissen ausgelöst werden, so behandelt, als ob sie aus einem Repository-Fork geöffnet worden wären. Im Gegensatz zu Workflows, die von anderen Akteuren ausgelöst werden, bedeutet dies, dass sie ein schreibgeschütztes GITHUB_TOKEN erhalten und keinen Zugriff auf Geheimnisse haben, die normalerweise verfügbar sind. Dies führt dazu, dass alle Workflows, die versuchen, in das Repository zu schreiben, fehlschlagen, wenn sie durch Dependabotausgelöst werden.
Es gibt drei Möglichkeiten, dieses Problem zu beheben:
- Sie können Ihre Workflows so aktualisieren, dass sie nicht länger durch Dependabot ausgelöst werden, und dazu einen Ausdruck wie diesen verwenden:
if: github.actor != 'dependabot[bot]'. 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. - Sie können Workflows bereitstellen, die durch den Zugriff auf Geheimnisse über Dependabot ausgelöst werden, und dem Ausdruck
permissionsermöglichen, den Standardbereich vonGITHUB_TOKENzu erweitern.
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 Geheimnisse, die dem Workflow zur Verfügung stehen, Dependabot-Geheimnisse. 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.