# Fehlerbehebung für Dependabot in GitHub Actions

Dieser Artikel enthält Informationen zur Problembehandlung bei Problemen, die bei der Verwendung von Dependabot mit GitHub Actions auftreten können.

## Problembehandlung bei Fehlern, wenn Dependabot vorhandene Workflows auslöst

Nachdem du Dependabot für GitHub.com 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:

1. 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](/de/actions/learn-github-actions/expressions).
2. Du kannst deine Workflows so ändern, dass sie einen zweistufigen Prozess mit `pull_request_target` verwenden, das nicht diesen Einschränkungen unterliegt. Weitere Informationen finden Sie unter [Fehlerbehebung für Dependabot in GitHub Actions](/de/code-security/dependabot/troubleshooting-dependabot/troubleshooting-dependabot-on-github-actions#restrictions-when-dependabot-triggers-events).
3. Du kannst Workflows bereitstellen, die durch den Dependabot-Zugriff auf Geheimnisse ausgelöst werden, und es dem Term `permissions` erlauben, den Standardbereich von `GITHUB_TOKEN` zu erhöhen.

In diesem Artikel werden Hinweise zur Problembehandlung bereitgestellt. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions).

### 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](/de/code-security/dependabot/working-with-dependabot/configuring-access-to-private-registries-for-dependabot#storing-credentials-for-dependabot-to-use).

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](/de/actions/security-guides/encrypted-secrets#using-encrypted-secrets-in-a-workflow).

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](/de/code-security/dependabot/working-with-dependabot/automating-dependabot-with-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.

```yaml copy
# 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:

```yaml copy
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](/de/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token).

## 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](/de/actions/managing-workflow-runs/re-running-workflows-and-jobs).