Skip to main content

Устранение неполадок зависимостей от действий GitHub

В этой статье содержатся сведения об устранении неполадок, которые могут возникнуть при использовании Dependabot с GitHub Actions.

Ограничения, когда Dependabot активирует события

Dependabot может активировать рабочие процессы GitHub Actions в запросах на вытягивание и комментариях; однако некоторые события обрабатываются иначе.

Для рабочих процессов, инициированных Dependabot (github.actor == 'dependabot[bot]') с помощью pull_request, , pull_request_review, pull_request_review_comment, push``createи deployment``deployment_status событий, применяются следующие ограничения:

  • GITHUB_TOKEN имеет разрешения только для чтения по умолчанию.
  • Секреты заполняются секретами из секретов Dependabot. Секреты GitHub Actions недоступны.

Для рабочих процессов, инициированных Dependabot (github.actor == 'dependabot[bot]') с помощью pull_request_target события, если базовый ссылок запроса на вытягивание был создан Dependabot (),github.event.pull_request.user.login == 'dependabot[bot]' доступ к ним будет доступен только для чтения, GITHUB_TOKEN а секреты недоступны.

Эти ограничения применяются, даже если рабочий процесс повторно выполняется другим субъектом.

Дополнительные сведения см. в статье "Защита действий и рабочих процессов GitHub: предотвращение запросов pwn".

Устранение неполадок при активации существующих рабочих процессов в Dependabot

После настройки обновлений 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, которое не имеет таких ограничений. Дополнительные сведения см. в разделе Устранение неполадок зависимостей от действий GitHub.
  3. Вы можете предоставить рабочим процессам, активируемым из Dependabot, доступ к секретам и разрешить термину permissions увеличивать область GITHUB_TOKEN по умолчанию.

Некоторые рекомендации по устранению неполадок приведены в этой статье. Вы также можете увидеть Синтаксис рабочего процесса для GitHub Actions.

Доступ к секретам

Когда событие Dependabot активирует рабочий процесс, единственными секретами, доступными для рабочего процесса, являются секреты Dependabot. Секреты GitHub Actions недоступны. Поэтому необходимо хранить все секреты, которые используются рабочим процессом, инициируемыми событиями Dependabot в виде секретов Dependabot. Дополнительные сведения см. в разделе Настройка доступа к частным реестрам для Dependabot.

Секреты Dependabot добавляются в контекст secrets, и ссылки на них имеют точно такой же синтаксис, что и секреты для GitHub Actions. Дополнительные сведения см. в разделе Использование секретов в GitHub Actions.

Если у вас есть рабочий процесс, который будет активироваться Dependabot, а также другими субъектами, проще всего сохранить маркер с необходимыми разрешениями в действии и в секрете Dependabot с идентичными именами. Затем рабочий процесс может включать один вызов этих секретов. Если у секрета для Dependabot другое имя, используйте условия, чтобы указать правильные секреты для различных субъектов.

Примеры использования условий см. в разделе Автоматизация Dependabot с помощью GitHub Actions.

Чтобы получить доступ к частному реестру контейнеров в AWS с именем пользователя и паролем, рабочий процесс должен содержать секрет для username и password.

В этом примере, когда Dependabot активирует рабочий процесс, секреты Dependabot с именами READONLY_AWS_ACCESS_KEY_ID и READONLY_AWS_ACCESS_KEY используются. Если другой субъект активирует рабочий процесс, используются секреты действий с этими именами.

YAML
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)

Изменение разрешений GITHUB_TOKEN

По умолчанию рабочие процессы GitHub Actions, активированныеDependabot, получают GITHUB_TOKEN с разрешениями только на чтение. В рабочем процессе можно использовать ключ permissions для увеличения доступа к маркеру:

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

Дополнительные сведения см. в разделе Автоматическая проверка подлинности токенов.

Повторный запуск рабочего процесса вручную

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