GITHUB_TOKEN

Узнайте, что GITHUB_TOKEN такое работа, как это работает и почему это важно для безопасной автоматизации рабочих GitHub Actions процессов.

В этой статье

Сведения о GITHUB_TOKEN

В начале каждого рабочего процесса GitHub автоматически создаётся уникальный GITHUB_TOKEN секрет для использования в вашем рабочем процессе. Вы можете использовать GITHUB_TOKEN проверку подлинности в задании рабочего процесса.

Когда вы включите GitHub Actions, GitHub устанавливает приложение GitHub App в ваш репозиторий. Секрет — это GitHub App токен доступа для GITHUB_TOKEN установки. Вы можете использовать токен доступа установки для аутентификации от имени установленного GitHub App в вашем репозитории. Разрешения маркера ограничены репозиторием, содержащим рабочий процесс. Для получения дополнительной информации см. Синтаксис рабочего процесса для GitHub Actions.

Перед началом GitHub каждой задачи получается токен доступа для установки. Срок GITHUB_TOKEN истекает после завершения работы или после её эффективного максимального срока службы.

Эффективный максимальный срок службы токена зависит от типа бегуна:

  • GitHub-хостированные бегуны Максимальное время выполнения работы составляет 6 часов, поэтому GITHUB_TOKEN они могут жить максимум 6 часов.
  • Самоведущие бегуны Максимальное время выполнения задания — 5 дней. Однако, поскольку GITHUB_TOKEN является токеном установки access, его можно обновлять только до 24 часов. Если ваша работа длится более 24 часов, используйте personal access token другой способ аутентификации.

Токен также доступен в контексте github.token. Для получения дополнительной информации см. Справочник по контекстам.

При GITHUB_TOKEN запуске рабочего процесса триггеров

Когда вы используете репозитории GITHUB_TOKEN для выполнения задач, события, вызванные ими, GITHUB_TOKEN не создадут новый рабочий процесс, за следующими исключениями:

  • workflow_dispatch А repository_dispatch события всегда создают запуски рабочих процессов.
  • pull_requestсобытия с , или типами активности: когда рабочий процесс с GITHUB_TOKEN использованием pull-запроса создаёт или обновляется, возникающее pull_request событие создаёт рабочий процесс в состоянии, требуемом одобрения.reopened``synchronize``opened Pull-запрос отображает баннер в окне слияния, и пользователь с доступом к записи в репозиторий может начать запуски, выбрав Approve workflows для запуска. Другие pull_request типы активности (такие как labeled, edited, или closed) не создают запуски рабочих процессов. Это предотвращает рекурсивные запуски рабочих процессов, при этом позволяя CI-рабочим процессам запускаться на пулл-запросах, созданных автоматизацией. Для получения дополнительной информации об одобрении запусков рабочих процессов см. Утверждение рабочих процессов выполняется из вилок.

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

Примечание.

Если вам нужен рабочий процесс, который запускается от pull-запросов, созданных рабочим процессом, и выполняется без необходимости одобрения, используйте GitHub App токен доступа установки или personal access token а вместо GITHUB_TOKEN этого при создании или обновлении pull request.

Фиксации, отправленные рабочим процессом GitHub Actions с использованием GITHUB_TOKEN сборки GitHub Pages.

Следующие шаги