Troubleshooting Dependabot on GitHub Actions

Restrictions when Dependabot triggers events

Dependabot is able to trigger GitHub Actions workflows on its pull requests and comments; however, certain events are treated differently.

For workflows initiated by Dependabot (github.actor == 'dependabot[bot]') using the pull_request, pull_request_review, pull_request_review_comment, push, create, deployment, and deployment_status events, these restrictions apply:

• GITHUB_TOKEN has read-only permissions by default.
• Secrets are populated from Dependabot secrets. GitHub Actions secrets are not available.

For workflows initiated by Dependabot (github.actor == 'dependabot[bot]') using the pull_request_target event, if the base ref of the pull request was created by Dependabot (github.event.pull_request.user.login == 'dependabot[bot]'), the GITHUB_TOKEN will be read-only and secrets are not available.

These restrictions apply even if the workflow is re-run by a different actor.

For more information, see Keeping your GitHub Actions and workflows secure: Preventing pwn requests.

Troubleshooting failures when Dependabot triggers existing workflows

После настройки обновлений Dependabot для GitHub.comмогут возникнуть сбои при активации существующих рабочих процессов событиями Dependabot .

По умолчанию запуски рабочих процессов GitHub Actions, которые активируются Dependabot при наступлении событий push, pull_request, pull_request_review или pull_request_review_comment, обрабатываются так, как если бы они были открыты из вилки репозитория. Это означает, что в отличие от рабочих процессов, активированных другими субъектами, они получают GITHUB_TOKEN только для чтения и не имеют доступа к секретам, которые обычно доступны. Это приводит к сбою любых рабочих процессов, которые пытаются выполнить запись в репозиторий при активации из Dependabot.

Существует три способа решения этой проблемы.

1. Вы можете изменить рабочие процессы так, чтобы они больше не активировались из Dependabot, с помощью следующего выражения: if: github.actor != 'dependabot[bot]'. Дополнительные сведения см. в разделе Оценка выражений в рабочих процессах и действиях.
2. Вы можете изменить рабочие процессы так, чтобы использовался двухэтапный процесс с событием pull_request_target, которое не имеет таких ограничений. Дополнительные сведения см. в разделе Автоматизация Dependabot с помощью GitHub Actions.
3. Вы можете предоставить рабочим процессам, активируемым из Dependabot, доступ к секретам и разрешить термину permissions увеличивать область GITHUB_TOKEN по умолчанию.

Some troubleshooting advice is provided in this article. You can also see Синтаксис рабочего процесса для GitHub Actions.

Accessing secrets

When a Dependabot event triggers a workflow, the only secrets available to the workflow are Dependabot secrets. GitHub Actions secrets are not available. You must therefore store any secrets that are used by a workflow triggered by Dependabot events as Dependabot secrets. For more information, see Настройка доступа к частным реестрам для Dependabot.

Dependabot secrets are added to the secrets context and referenced using exactly the same syntax as secrets for GitHub Actions. For more information, see Использование секретов в GitHub Actions.

If you have a workflow that will be triggered by Dependabot and also by other actors, the simplest solution is to store the token with the permissions required in an action and in a Dependabot secret with identical names. Then the workflow can include a single call to these secrets. If the secret for Dependabot has a different name, use conditions to specify the correct secrets for different actors to use.

For examples that use conditions, see Автоматизация Dependabot с помощью GitHub Actions.

To access a private container registry on AWS with a user name and password, a workflow must include a secret for username and password.

In this example, when Dependabot triggers the workflow, the Dependabot secrets with the names READONLY_AWS_ACCESS_KEY_ID and READONLY_AWS_ACCESS_KEY are used. If another actor triggers the workflow, the actions secrets with those names are used.

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)

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)

Changing GITHUB_TOKEN permissions

By default, GitHub Actions workflows triggered by Dependabot get a GITHUB_TOKEN with read-only permissions. You can use the permissions key in your workflow to increase the access for the token:

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:
  ...

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:
  ...

For more information, see Автоматическая проверка подлинности токенов.

Manually re-running a workflow

When you manually re-run a Dependabot workflow, it will run with the same privileges as before even if the user who initiated the rerun has different privileges. For more information, see Повторный запуск рабочих процессов и заданий.