# GITHUB_TOKEN

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

## Сведения о `GITHUB_TOKEN`

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

Когда вы включите GitHub Actions, GitHub устанавливает приложение GitHub App в ваш репозиторий. Секрет — это `GITHUB_TOKEN` токен доступа для GitHub App установки. Вы можете использовать токен доступа установки для аутентификации от имени установленного GitHub App в вашем репозитории. Разрешения маркера ограничены репозиторием, содержащим рабочий процесс. Для получения дополнительной информации см. [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#permissions).

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

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

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

Токен также доступен в контексте `github.token`. Для получения дополнительной информации см. [Справочник по контекстам](/ru/actions/reference/workflows-and-actions/contexts#github-context).

## При `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-рабочим процессам запускаться на пулл-запросах, созданных автоматизацией. Для получения дополнительной информации об одобрении запусков рабочих процессов см. [Утверждение рабочих процессов выполняется из вилок](/ru/actions/how-tos/manage-workflow-runs/approve-runs-from-forks).

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

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

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

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

* [автозаголовок](/ru/actions/tutorials/authenticate-with-github_token)
* [автозаголовок](/ru/actions/reference/workflows-and-actions/workflow-syntax#permissions)