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

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

После настройки обновлений Dependabot для ваш экземпляр GitHub Enterprise Serverмогут возникнуть сбои при активации существующих рабочих процессов событиями 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 именами. Если другой субъект активирует рабочий процесс, используются секреты действий с этими именами.

# Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# Они предоставляются сторонним поставщиком, и на них распространяются
# отдельные условия обслуживания, политика конфиденциальности и поддержка
# документации.
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)

# Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# Они предоставляются сторонним поставщиком, и на них распространяются
# отдельные условия обслуживания, политика конфиденциальности и поддержка
# документации.
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)

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

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

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

Дополнительные сведения см. в разделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах.

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

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