# События, инициирующие рабочие процессы
Вы можете настроить рабочие процессы так, чтобы они запускались при конкретной активности GitHub , в запланированное время или когда происходит событие вне нее GitHub .
## Сведения о событиях, которые активируют рабочие процессы
Триггеры рабочего процесса — это события, которые приводят к запуску рабочего процесса. Дополнительные сведения об использовании триггеров рабочего процесса см. в разделе [Активация рабочего процесса](/ru/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow).
Некоторые события предусматривают несколько типов действий. Для таких событий можно указать типы действий, которые будут активировать рабочий процесс. Дополнительные сведения о том, что означает каждый тип действия, см. в разделе [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads).
> \[!NOTE]
> Не все события веб-перехватчика активируют рабочие процессы.
## `branch_protection_rule`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------------- | ------------------------------------------ | --------------------------------------- | ------------------ |
| [`branch_protection_rule`](/ru/webhooks/webhook-events-and-payloads#branch_protection_rule) | - `created`
- `edited`
- `deleted` | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> \*
> Это событие активируется несколькими типами действий. Для информации о каждом типе активности см. [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#branch_protection_rule). По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
Это событие запускает рабочий процесс при изменении правил защиты ветви в репозитории рабочих процессов. Дополнительные сведения о правилах защиты ветви см. в разделе [Сведения о защищенных ветвях](/ru/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches). Сведения об API-интерфейсах правил защиты ветви см\[. в документации по API GraphQL или [Branches](/ru/graphql/reference/branches#object-branchprotectionrule)]\(/rest/branches).
Например, можно запустить рабочий процесс, если к правилу защиты ветви был применен тип действия `created` или `deleted`:
```yaml
on:
branch_protection_rule:
types: [created, deleted]
```
## `check_run`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------- | -------------------------------------------------------------------------- | --------------------------------------- | ------------------ |
| [`check_run`](/ru/webhooks/webhook-events-and-payloads#check_run) | - `created`
- `rerequested`
- `completed`
- `requested_action` | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> \*
> Это событие активируется несколькими типами действий. Для информации о каждом типе активности см. [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#check_run). По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
> * Чтобы предотвратить рекурсивные рабочие процессы, это событие не запускает рабочие процессы, если набор проверки был создан GitHub Actions или если головная SHA контрольной группы связана с GitHub Actions.
Это событие запускает рабочий процесс при действии, связанном с выполнением проверки. Выполнение проверки — это отдельный тест, входящий в состав набора проверок. Дополнительные сведения см. в разделе [Использование REST API для взаимодействия с проверками](/ru/rest/guides/using-the-rest-api-to-interact-with-checks). Сведения об API проверки выполнения см\[. в документации по API GraphQL или [Чеки](/ru/graphql/reference/checks#object-checkrun)]\(/rest/checks/runs).
Например, можно запустить рабочий процесс, если проверка имеет тип действия `rerequested` или `completed`.
```yaml
on:
check_run:
types: [rerequested, completed]
```
## `check_suite`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------------------------------------- | ------------- | --------------------------------------- | ------------------ |
| [`check_suite`](/ru/webhooks/webhook-events-and-payloads#check_suite) | - `completed` | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> \*
> Это событие активируется несколькими типами действий. Для информации о каждом типе активности см. [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#check_suite). Несмотря на то, что поддерживается только тип действия `completed`, указание типа действия позволит сохранить специфичность рабочего процесса, что важно при добавлении других типов действия в будущем. По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
> * Чтобы предотвратить рекурсивные рабочие процессы, это событие не запускает рабочие процессы, если набор проверок был создан GitHub Actions или если главный SHA набора чек-пакета связан с GitHub Actions.
Это событие запускает рабочий процесс при выполнении действий, связанных с набором проверок. Набор проверок — это коллекция запусков проверок, созданных для определенной фиксации. Набор проверок позволяет получить общее заключение о состоянии выполнения проверок, входящих в состав набора. Дополнительные сведения см. в разделе [Использование REST API для взаимодействия с проверками](/ru/rest/guides/using-the-rest-api-to-interact-with-checks). Сведения об API набора check suite см\[. в документации по API GraphQL или [Чеки](/ru/graphql/reference/checks#object-checksuite)]\(/rest/checks/suites).
Например, можно запустить рабочий процесс, если набор проверок находится в состоянии `completed`.
```yaml
on:
check_suite:
types: [completed]
```
## `create`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------- | ------------- | --------------------------------------------- | ----------------------- |
| [`create`](/ru/webhooks/webhook-events-and-payloads#create) | Нет данных | Последняя фиксация в созданной ветви или теге | Созданная ветвь или тег |
> \[!NOTE]
> Событие не будет создано при создании более трех тегов одновременно.
Это событие запускает рабочий процесс при создании ссылки на Git (ветвь или тег Git) из репозитория рабочего процесса. Сведения об API-интерфейсах для создания ссылки на Git см\[. в документации по API GraphQL или [Git](/ru/graphql/reference/git#mutation-createref)]\(/rest/git/refs#create-a-reference).
Например, можно запустить рабочий процесс при возникновении события `create`.
```yaml
on:
create
```
## `delete`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------- | ------------- | --------------------------------------- | ------------------ |
| [`delete`](/ru/webhooks/webhook-events-and-payloads#delete) | Нет данных | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
>
> * Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
> * Событие не будет создано при удалении более трех тегов одновременно.
Это событие запускает рабочий процесс при удалении ссылки на Git (ветвь или тег Git) из репозитория рабочего процесса. Сведения об API-интерфейсах для удаления ссылки на Git см\[. в документации по API GraphQL или [Git](/ru/graphql/reference/git#mutation-deleteref)]\(/rest/git/refs#delete-a-reference).
Например, можно запустить рабочий процесс при возникновении события `delete`.
```yaml
on:
delete
```
## `deployment`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------- | ------------- | -------------------------- | ---------------------------------------------------------------------- |
| [`deployment`](/ru/webhooks/webhook-events-and-payloads#deployment) | Нет данных | Фиксация для развертывания | Ветвь или тег для развертывания (пустые, если созданы с фиксацией SHA) |
Это событие запускает рабочий процесс при создании развертывания в репозитории рабочего процесса. Развертывания, созданные с фиксацией SHA, могут не иметь ссылки на Git. Сведения об API-интерфейсах для создания развертывания см\[. в документации по API GraphQL или [Deployments](/ru/graphql/reference/deployments#mutation-createdeployment)]\(/rest/repos#deployments).
Например, можно запустить рабочий процесс при возникновении события `deployment`.
```yaml
on:
deployment
```
## `deployment_status`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------------------------------------------------- | ------------- | -------------------------- | ------------------------------------------------------------ |
| [`deployment_status`](/ru/webhooks/webhook-events-and-payloads#deployment_status) | Нет данных | Фиксация для развертывания | Ветвь или тег для развертывания (пустые, если есть фиксация) |
> \[!NOTE]
> Если задано `inactive`состояние состояния развертывания, запуск рабочего процесса не будет активирован.
Это событие запускает рабочий процесс, когда состояние развертывания предоставляется третьей стороной. Развертывания, созданные с фиксацией SHA, могут не иметь ссылки на Git. Сведения об API-интерфейсах для создания состояния развертывания см\[. в документации по API GraphQL или [Deployments](/ru/graphql/reference/deployments#mutation-createdeploymentstatus)]\(/rest/deployments#create-a-deployment-status).
Например, можно запустить рабочий процесс при возникновении события `deployment_status`.
```yaml
on:
deployment_status
```
## `discussion`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | ------------------ |
| [`discussion`](/ru/webhooks/webhook-events-and-payloads#discussion) | - `created`
- `edited`
- `deleted`
- `transferred`
- `pinned`
- `unpinned`
- `labeled`
- `unlabeled`
- `locked`
- `unlocked`
- `category_changed`
- `answered`
- `unanswered` | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> \*
> Это событие активируется несколькими типами действий. Для информации о каждом типе активности см. [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#discussion). По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
> * События веб-перехватчика для GitHub Discussions в настоящее время находятся в Публичный предварительный просмотр и подлежат изменению.
Это событие запускает рабочий процесс при создании или изменении обсуждения в репозитории рабочего процесса. Для действий, связанных с комментариями к обсуждению, используйте событие [`discussion_comment`](#discussion_comment). Дополнительные сведения о обсуждениях см. в разделе [Сведения об обсуждениях](/ru/discussions/collaborating-with-your-community-using-discussions/about-discussions). Сведения об API GraphQL см. в разделе [Обсуждения](/ru/graphql/reference/discussions#object-discussion).
Например, можно запустить рабочий процесс, если обсуждение имеет тип действия `created`, `edited` или `answered`.
```yaml
on:
discussion:
types: [created, edited, answered]
```
## `discussion_comment`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------------------------- | ----------------------------------------------- | --------------------------------------- | ------------------ |
| [`discussion_comment`](/ru/webhooks/webhook-events-and-payloads#discussion_comment) | - `created`
- `edited`
- `deleted`
| Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> \*
> Это событие активируется несколькими типами действий. Для информации о каждом типе активности см. [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#discussion_comment). По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
> * События веб-перехватчика для GitHub Discussions в настоящее время находятся в Публичный предварительный просмотр и подлежат изменению.
Это событие запускает рабочий процесс при создании или изменении комментария к обсуждению в репозитории рабочего процесса. Для действий, связанных с обсуждением, а не с комментариями к нему, используйте событие [`discussion`](#discussion). Дополнительные сведения о обсуждениях см. в разделе [Сведения об обсуждениях](/ru/discussions/collaborating-with-your-community-using-discussions/about-discussions). Сведения об API GraphQL см. в разделе [Обсуждения](/ru/graphql/reference/discussions#object-discussion).
Например, можно запустить рабочий процесс, если комментарий к обсуждению имеет тип действия `created` или `deleted`.
```yaml
on:
discussion_comment:
types: [created, deleted]
```
## `fork`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------- | ------------- | --------------------------------------- | ------------------ |
| [`fork`](/ru/webhooks/webhook-events-and-payloads#fork) | Нет данных | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
Это событие запускает рабочий процесс при создании вилки репозитория. Сведения о REST API см. в разделе [Конечные точки REST API для вилок](/ru/rest/repos/forks#create-a-fork).
Например, можно запустить рабочий процесс при возникновении события `fork`.
```yaml
on:
fork
```
## `gollum`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------- | ------------- | --------------------------------------- | ------------------ |
| [`gollum`](/ru/webhooks/webhook-events-and-payloads#gollum) | Нет данных | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
Это событие запускает рабочий процесс при создании или обновлении вики-страницы. Дополнительные сведения см. в разделе [Сведения о вики-сайтах](/ru/communities/documenting-your-project-with-wikis/about-wikis).
Например, можно запустить рабочий процесс при возникновении события `gollum`.
```yaml
on:
gollum
```
## `image_version`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------- | ------------- | --------------------------------------- | ------------------ |
| Нет данных | Нет данных | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
Запускает рабочий процесс, когда новая версия указанного изображения становится доступной для использования. Это событие обычно запускается после успешного создания версии образа, что позволяет автоматизировать такие действия, как развертывание или уведомления в ответ на новые версии образа.
Это событие поддерживает глобальные шаблоны как для имен образов, так и для версий. Приведенный ниже пример срабатывает, когда новая версия образа соответствует любой из указанных комбинаций имени и версии. Например, `["MyNewImage", 1.0.0]`, `["MyNewImage", 2.53.0]`, `["MyOtherImage", 1.0.0]`, и `["MyOtherImage", 2.0.0]`.
```yaml
on:
image_version:
names:
- "MyNewImage"
- "MyOtherImage"
versions:
- 1.*
- 2.*
```
## `issue_comment`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------- | ----------------------------------------------- | --------------------------------------- | ------------------ |
| [`issue_comment`](/ru/webhooks/webhook-events-and-payloads#issue_comment) | - `created`
- `edited`
- `deleted`
| Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> \*
> Это событие активируется несколькими типами действий. Для информации о каждом типе активности см. [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#issue_comment). По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
Это событие запускает рабочий процесс при создании, изменении или удалении комментария к проблеме или запросу на вытягивание. Сведения об API комментариев проблемы см\[. в документации по API GraphQL или [Проблемы](/ru/graphql/reference/issues#object-issuecomment)]\(/webhooks/webhook-events-and-payloads#issue\_comment) в документации по REST API.
Например, можно запустить рабочий процесс, если к комментарию к проблеме или запросу на вытягивание применено действие `created` или `deleted`.
```yaml
on:
issue_comment:
types: [created, deleted]
```
### `issue_comment` только для проблем или только для запросов на вытягивание
Событие `issue_comment` возникает как для комментариев к проблемам, так и для комментариев к запросам на вытягивание. Свойство `github.event.issue.pull_request` можно использовать в условном режиме для выполнения различных действий в зависимости от того, был ли объект-триггер проблемой или запросом на вытягивание.
Например, этот рабочий процесс будет выполнять задание `pr_commented`, только если событие `issue_comment` возникло из запроса на вытягивание. Этот рабочий процесс будет запускать задание `issue_commented`, только если событие `issue_comment` возникло из проблемы.
```yaml
on: issue_comment
jobs:
pr_commented:
# This job only runs for pull request comments
name: PR comment
if: ${{ github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo A comment on PR $NUMBER
env:
NUMBER: ${{ github.event.issue.number }}
issue_commented:
# This job only runs for issue comments
name: Issue comment
if: ${{ !github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo A comment on issue $NUMBER
env:
NUMBER: ${{ github.event.issue.number }}
```
## `issues`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | ------------------ |
| [`issues`](/ru/webhooks/webhook-events-and-payloads#issues) | - `opened`
- `edited`
- `deleted`
- `transferred`
- `pinned`
- `unpinned`
- `closed`
- `reopened`
- `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `locked`
- `unlocked`
- `milestoned`
- `demilestoned`
- `typed`
- `untyped`
- `field_added`
- `field_removed` | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> \*
> Это событие активируется несколькими типами действий. Для информации о каждом типе активности см. [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#issues). По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
Это событие запускает рабочий процесс при создании или изменении проблемы в репозитории рабочего процесса. Для действий, связанных с комментариями к проблеме, используйте событие [`issue_comment`](#issue_comment). Дополнительные сведения о проблемах см. в разделе [О проблемах](/ru/issues/tracking-your-work-with-issues/learning-about-issues/about-issues). Сведения об API-интерфейсах проблемы см\[. в документации по API GraphQL или [Проблемы](/ru/graphql/reference/issues#object-issue)]\(/rest/issues).
Например, можно запустить рабочий процесс, если к проблеме было применено действие `opened`, `edited` или `milestoned`.
```yaml
on:
issues:
types: [opened, edited, milestoned]
```
Вы также можете запустить рабочий процесс, когда значение поля проблемы установлено, изменено или очищено.
`field_added` Тип активности срабатывает как при первоначальной установке значения поля, так и при обновлении существующего значения.
`field_removed` Тип активности срабатывает, когда значение поля очищается.
```yaml
on:
issues:
types: [field_added, field_removed]
```
## `label`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------------------------- | ----------------------------------------------- | --------------------------------------- | ------------------ |
| [`label`](/ru/webhooks/webhook-events-and-payloads#label) | - `created`
- `edited`
- `deleted`
| Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> \*
> Это событие активируется несколькими типами действий. Для информации о каждом типе активности см. [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#label). По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
Это событие запускает рабочий процесс при создании или изменении метки в репозитории рабочего процесса. Дополнительные сведения о метках см. в разделе [Управление метками](/ru/issues/using-labels-and-milestones-to-track-work/managing-labels). Сведения об API меток см\[. в документации по API GraphQL или [Проблемы](/ru/graphql/reference/issues#object-label)]\(/rest/issues/labels).
Чтобы запустить рабочий процесс при добавлении метки в проблему, запрос на вытягивание или обсуждение либо при удалении метки, используйте типы действий `labeled` или `unlabeled` для событий [`issues`](#issues), [`pull_request`](#pull_request), [`pull_request_target`](#pull_request_target) или [`discussion`](#discussion).
Например, можно запустить рабочий процесс, если к метке было применено действие `created` или `deleted`.
```yaml
on:
label:
types: [created, deleted]
```
## `merge_group`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------------------------------------- | ------------------ | ------------------ | ------------------------ |
| [`merge_group`](/ru/webhooks/webhook-events-and-payloads#merge_group) | `checks_requested` | SHA группы слияния | Ссылка на группу слияния |
> \[!NOTE]
>
> *
Это событие активируется несколькими типами действий. Хотя поддерживается только `checks_requested` тип активности, указание типа активности сохранит ваш рабочий процесс специфическим при добавлении новых типов активности в будущем. Сведения о каждом типе действия см. в разделе [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#merge_group). По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
> * Если репозиторий использует GitHub Actions для выполнения обязательных проверок на запросы на вытягивание в репозитории, необходимо обновить рабочие процессы, чтобы включить `merge_group` событие в качестве дополнительного триггера. В противном случае проверки состояния не будут активированы при добавлении запроса на вытягивание в очередь слияния. Слияние завершится ошибкой, так как обязательная проверка состояния не будет сообщаться. Событие `merge_group` отличается от `pull_request` событий и `push` событий.
Запускает рабочий процесс при добавлении запроса на вытягивание в очередь слияния, которая добавляет запрос на вытягивание в группу слияния. Дополнительные сведения см. в разделе [Слияние для запроса на вытягивание с очередью слияния](/ru/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request-with-a-merge-queue).
Например, можно выполнить рабочий процесс при возникновении действия `checks_requested`.
```yaml
on:
pull_request:
branches: [ "main" ]
merge_group:
types: [checks_requested]
```
## `milestone`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------- | ----------------------------------------------------------------------------- | --------------------------------------- | ------------------ |
| [`milestone`](/ru/webhooks/webhook-events-and-payloads#milestone) | - `created`
- `closed`
- `opened`
- `edited`
- `deleted`
| Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> \*
> Это событие активируется несколькими типами действий. Для информации о каждом типе активности см. [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#milestone). По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
Это событие запускает рабочий процесс при создании или изменении вехи в репозитории рабочего процесса. Дополнительные сведения о вех см. в разделе [Сведения о вехах](/ru/issues/using-labels-and-milestones-to-track-work/about-milestones). Сведения об API-интерфейсах вехи см\[. в документации по API GraphQL или [Проблемы](/ru/graphql/reference/issues#object-milestone)]\(/rest/issues/milestones).
Чтобы запустить рабочий процесс при добавлении проблемы в веху или ее удалении из вехи, используйте тип действия `milestoned` или `demilestoned` для события [`issues`](#issues).
Например, можно запустить рабочий процесс, если к вехе было применено действие `opened` или `deleted`.
```yaml
on:
milestone:
types: [opened, deleted]
```
## `page_build`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------- | ------------- | --------------------------------------- | ------------------ |
| [`page_build`](/ru/webhooks/webhook-events-and-payloads#page_build) | Нет данных | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
Запускает ваш рабочий процесс, когда кто-то отправляет в ветку, которая является источником публикации для GitHub Pages, если GitHub Pages включена для репозитория. Для получения дополнительной информации о GitHub Pages источниках публикации см. [AUTOTITLE.](/ru/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site) Сведения о REST API см. в разделе [Конечные точки REST API для репозиториев](/ru/rest/repos#pages).
Например, можно запустить рабочий процесс при возникновении события `page_build`.
```yaml
on:
page_build
```
## `public`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------- | ------------- | --------------------------------------- | ------------------ |
| [`public`](/ru/webhooks/webhook-events-and-payloads#public) | Нет данных | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
Это событие запускает рабочий процесс при изменении репозитория рабочего процесса с частного на общедоступный. Сведения о REST API см. в разделе [Конечные точки REST API для репозиториев](/ru/rest/repos#edit).
Например, можно запустить рабочий процесс при возникновении события `public`.
```yaml
on:
public
```
## `pull_request`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | ------------------------------------------------------ |
| [`pull_request`](/ru/webhooks/webhook-events-and-payloads#pull_request) | - `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `opened`
- `edited`
- `closed`
- `reopened`
- `synchronize`
- `converted_to_draft`
- `locked`
- `unlocked`
- `enqueued`
- `dequeued`
- `milestoned`
- `demilestoned`
- `ready_for_review`
- `review_requested`
- `review_request_removed`
- `auto_merge_enabled`
- `auto_merge_disabled` | Последняя фиксация слияния в ветви `GITHUB_REF` | Ветвь слияния PR `refs/pull/PULL_REQUEST_NUMBER/merge` |
> \[!NOTE]
> \*
> Это событие активируется несколькими типами действий. Для информации о каждом типе активности см. [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#pull_request). По умолчанию рабочий процесс выполняется только в том случае, если для типа действия события `pull_request` указано `opened`, `synchronize` или `reopened`. Чтобы активировать рабочие процессы с помощью других типов действий, используйте ключевое слово `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Рабочие процессы не будут выполняться в `pull_request` действии, если запрос на вытягивание имеет конфликт слияния. Сначала необходимо разрешить этот конфликт. Рабочие процессы с событием `pull_request_target`, напротив, будут выполняться даже при наличии конфликта слияния в запросе на вытягивание. Перед использованием триггера `pull_request_target` следует учесть риски безопасности. Дополнительные сведения см. в статье [`pull_request_target`](#pull_request_target).
> * Payload event webhook пуст для объединённых `pull_request` pull-запросов и pull-запросов, поступающих из форкированных репозиториев.
> * Когда потоковый запрос создаётся или обновляется рабочим процессом с `GITHUB_TOKEN`использованием , `pull_request` событий с `opened`, `synchronize`или `reopened` типов активности , создаются запуски рабочих процессов, требующих одобрения. Пользователь с правом записи в репозиторий может одобрить эти запуски со страницы pull request. За исключением `workflow_dispatch` и `repository_dispatch`, другие `GITHUB_TOKEN`-триггерные события вообще не создают запуски рабочих процессов.
> * Значение `GITHUB_REF` зависит от того, был ли объединенный запрос на вытягивание. Если запрос на вытягивание был закрыт, но не объединен, он будет `refs/pull/PULL_REQUEST_NUMBER/merge`. Если запрос на вытягивание был закрыт в результате объединения, он будет полностью объединен `ref` в ветвь, в которой он был объединен, например `/refs/heads/main`.
Это событие запускает рабочий процесс при выполнении действия по запросу на вытягивание в репозитории рабочего процесса. Например, если типы действий не указаны, рабочий процесс запускается при открытии или повторном открытии запроса на вытягивание либо при обновлении главной ветви запроса на вытягивание. Для действий, связанных с проверкой запросов на вытягивание, комментариями к проверкам запросов на вытягивание или комментариями к запросам на вытягивание, используйте событие [`pull_request_review`](#pull_request_review), [`pull_request_review_comment`](#pull_request_review_comment) или [`issue_comment`](#issue_comment). Сведения об API запроса на вытягивание см\[. в документации по API GraphQL или [Запросы на слияние](/ru/graphql/reference/pulls#object-pullrequest)]\(/rest/pulls).
Обратите внимание, что переменная `GITHUB_SHA` для этого события — это последняя фиксация слияния для ветви слияния запроса на вытягивание. Чтобы получить идентификатор фиксации для последней фиксации в главной ветви запроса на вытягивание, используйте переменную `github.event.pull_request.head.sha`. Для получения дополнительной информации о ветках слияния см. [раздел AUTOTITLE](/ru/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#pull-request-refs-and-merge-branches).
### Как ветка слияния влияет на ваш рабочий процесс
Для открытых, объединяемых pull-запросов — рабочие процессы, запускаемые событием `pull_request``GITHUB_REF` , установленным на ветку слияния. Поскольку `actions/checkout` по умолчанию использует `GITHUB_REF` использования, он проверяет ветку слияния. Ваши CI-тесты работают с объединённым результатом, а не только с головной ветвью:
* `GITHUB_REF` установлено в `refs/pull/PULL_REQUEST_NUMBER/merge`
* `GITHUB_SHA` является SHA коммита слияния на ветке слияния
Чтобы проверить только коммиты головной ветви без имитации слияния, посмотрите головную ветвь в `github.event.pull_request.head.sha` вашем рабочем процессе.
Например, можно запустить рабочий процесс при открытии или повторном открытии запроса на вытягивание.
```yaml
on:
pull_request:
types: [opened, reopened]
```
Контекст события можно использовать для дальнейшего управления выполнением заданий в рабочем процессе. Например, этот рабочий процесс будет выполняться при запросе проверки по запросу на вытягивание, но задание `specific_review_requested` будет выполняться, только если проверка запрошена командой `octo-team`.
```yaml
on:
pull_request:
types: [review_requested]
jobs:
specific_review_requested:
runs-on: ubuntu-latest
if: ${{ github.event.requested_team.name == 'octo-team'}}
steps:
- run: echo 'A review from octo-team was requested'
```
### `pull_request` Выполнение рабочего процесса на основе головы или базовая ветвь запроса на вытягивание
Используйте фильтр `branches` или `branches-ignore`, чтобы настроить запуск рабочего процесса только для запросов на вытягивание, предназначенных для конкретных ветвей. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore).
Например, этот рабочий процесс будет выполняться при открытии запроса на вытягивание, предназначенного для ветви, имя которой начинается с `releases/`:
```yaml
on:
pull_request:
types:
- opened
branches:
- 'releases/**'
```
> \[!NOTE]
> Если используется как фильтр `branches`, так и фильтр `paths`, рабочий процесс будет выполняться только при выполнении условий обоих фильтров. Например, следующий рабочий процесс будет выполняться только тогда, когда на ветке с названием : открывается pull-запрос, включающий изменение в JavaScript-файл (`.js`) на ветке, название которой начинается с `releases/`:
>
> ```yaml
> on:
> pull_request:
> types:
> - opened
> branches:
> - 'releases/**'
> paths:
> - '**.js'
> ```
Чтобы выполнить задание на основе имени главной ветви запроса на вытягивание (в отличие от имени базовой ветви запроса на вытягивание), используйте контекст `github.head_ref` в условном режиме. Например, этот рабочий процесс будет выполняться при каждом открытии запроса на вытягивание, но задание `run_if` будет выполняться только в том случае, если заголовок запроса на вытягивание является ветвью, имя которой начинается с `releases/`:
```yaml
on:
pull_request:
types:
- opened
jobs:
run_if:
if: startsWith(github.head_ref, 'releases/')
runs-on: ubuntu-latest
steps:
- run: echo "The head of this PR starts with 'releases/'"
```
### `pull_request` Выполнение рабочего процесса на основе файлов, измененных в запросе на вытягивание
Рабочий процесс можно настроить таким образом, чтобы он выполнялся при изменении определенных файлов в запросе на вытягивание. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore).
Например, этот рабочий процесс будет выполняться, когда в запросе на вытягивание изменен файл JavaScript (`.js`):
```yaml
on:
pull_request:
paths:
- '**.js'
```
> \[!NOTE]
> Если используется как фильтр `branches`, так и фильтр `paths`, рабочий процесс будет выполняться только при выполнении условий обоих фильтров. Например, следующий рабочий процесс будет выполняться только тогда, когда на ветке с названием : открывается pull-запрос, включающий изменение в JavaScript-файл (`.js`) на ветке, название которой начинается с `releases/`:
>
> ```yaml
> on:
> pull_request:
> types:
> - opened
> branches:
> - 'releases/**'
> paths:
> - '**.js'
> ```
### `pull_request` Выполнение рабочего процесса при слиянии запроса на вытягивание
При слиянии запрос на вытягивание автоматически закрывается. Чтобы запустить рабочий процесс при слиянии запроса на вытягивание, используйте тип события `pull_request``closed` вместе с условием, проверяющим значение `merged` события. Например, следующий рабочий процесс будет выполняться при закрытии запроса на вытягивание. Задание `if_merged` будет выполняться только в том случае, если произошло слияние запроса на вытягивание.
```yaml
on:
pull_request:
types:
- closed
jobs:
if_merged:
if: github.event.pull_request.merged == true
runs-on: ubuntu-latest
steps:
- run: |
echo The PR was merged
```
#### Рабочие процессы в вилках репозиториев
Рабочие процессы по умолчанию не выполняются в вилках репозиториев. Вы должны включить GitHub Actions на вкладке **Действия** в вилке репозитория.
За исключением `GITHUB_TOKEN`, секреты не передаются в средство выполнения при активации рабочего процесса из вилки репозитория. У `GITHUB_TOKEN` него есть разрешения только для чтения в запросах на вытягивание из вилки репозиториев. Дополнительные сведения см. в разделе [Использование GITHUB\_TOKEN для проверки подлинности в рабочих процессах](/ru/actions/security-guides/automatic-token-authentication).
#### События запросов на вытягивание для вилок репозиториев
Для запросов на вытягивание из вилированного репозитория в базовый репозиторий GitHub отправляет `pull_request`в базовый репозиторий , а `pull_request_review``issue_comment``pull_request_review_comment`также события , и `pull_request_target` события. В вилке репозитория никакие события запросов на вытягивание не происходят.
Когда новый участник отправляет запрос на вытягивание в общедоступный репозиторий, может потребоваться утверждение запущенных рабочих процессов в запросе на вытягивание ответственным лицом с правами на запись. Дополнительные сведения см. в разделе [Утверждение рабочих процессов выполняется из вилок](/ru/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks).
Запросы на вытягивание из вилированного репозитория в частный репозиторий выполняются только при включении рабочих процессов, см. в разделе [Управление настройками GitHub Actions для репозитория](/ru/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories).
> \[!NOTE]
> Рабочие процессы, активированные Dependabot запросы на вытягивание, обрабатываются так же, как если бы они были из вилированного репозитория, а также подвергаются этим ограничениям.
## `pull_request_comment` (используйте `issue_comment`)
Чтобы запустить рабочий процесс при создании, изменении или удалении комментария к запросу на вытягивание (а не к разнице запроса на вытягивание), используйте событие [`issue_comment`](#issue_comment). Для действий, связанных с проверкой запросов на вытягивание или комментариями к проверкам запросов на вытягивание, используйте событие [`pull_request_review`](#pull_request_review) или [`pull_request_review_comment`](#pull_request_review_comment).
## `pull_request_review`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------- | ---------------------------------------------- | ----------------------------------------------- | ------------------------------------------------------ |
| [`pull_request_review`](/ru/webhooks/webhook-events-and-payloads#pull_request_review) | - `submitted`
- `edited`
- `dismissed` | Последняя фиксация слияния в ветви `GITHUB_REF` | Ветвь слияния PR `refs/pull/PULL_REQUEST_NUMBER/merge` |
> \[!NOTE]
> Это событие активируется несколькими типами действий. Для информации о каждом типе активности см. [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#pull_request_review). По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
Это событие запускает рабочий процесс при отправке, изменении или закрытии проверки запроса на вытягивание. Проверка запроса на вытягивание — это группа комментариев к проверке запроса на вытягивание, дополняющих комментарии к тексту запроса и его состояние. Для действий, связанных с комментариями к проверкам запросов на вытягивание или комментариями к запросам на вытягивание, используйте событие [`pull_request_review_comment`](#pull_request_review_comment) или [`issue_comment`](#issue_comment). Сведения об ПРОВЕРКА ЗАПРОСА НА ВЫТЯГИВАНИЕ API см\[. в документации по API GraphQL или [Запросы на слияние](/ru/graphql/reference/pulls#object-pullrequest)]\(/rest/pulls#reviews).
Например, можно запустить рабочий процесс, если к проверке запроса на вытягивание применен тип действия `edited` или `dismissed`.
```yaml
on:
pull_request_review:
types: [edited, dismissed]
```
### Запуск рабочего процесса при утверждении запроса на вытягивание
Чтобы запустить рабочий процесс при утверждении запроса на вытягивание, активируйте рабочий процесс, используя тип `submitted` события `pull_request_review`, а затем проверьте состояние проверки, используя свойство `github.event.review.state`. Например, этот рабочий процесс будет выполняться при отправке проверки запроса на вытягивание, однако задание `approved` будет выполняться, только если отправленная проверка утверждена:
```yaml
on:
pull_request_review:
types: [submitted]
jobs:
approved:
if: github.event.review.state == 'approved'
runs-on: ubuntu-latest
steps:
- run: echo "This PR was approved"
```
#### Рабочие процессы в вилках репозиториев
Рабочие процессы по умолчанию не выполняются в вилках репозиториев. Вы должны включить GitHub Actions на вкладке **Действия** в вилке репозитория.
За исключением `GITHUB_TOKEN`, секреты не передаются в средство выполнения при активации рабочего процесса из вилки репозитория. У `GITHUB_TOKEN` него есть разрешения только для чтения в запросах на вытягивание из вилки репозиториев. Дополнительные сведения см. в разделе [Использование GITHUB\_TOKEN для проверки подлинности в рабочих процессах](/ru/actions/security-guides/automatic-token-authentication).
#### События запросов на вытягивание для вилок репозиториев
Для запросов на вытягивание из вилированного репозитория в базовый репозиторий GitHub отправляет `pull_request`в базовый репозиторий , а `pull_request_review``issue_comment``pull_request_review_comment`также события , и `pull_request_target` события. В вилке репозитория никакие события запросов на вытягивание не происходят.
Когда новый участник отправляет запрос на вытягивание в общедоступный репозиторий, может потребоваться утверждение запущенных рабочих процессов в запросе на вытягивание ответственным лицом с правами на запись. Дополнительные сведения см. в разделе [Утверждение рабочих процессов выполняется из вилок](/ru/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks).
Запросы на вытягивание из вилированного репозитория в частный репозиторий выполняются только при включении рабочих процессов, см. в разделе [Управление настройками GitHub Actions для репозитория](/ru/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories).
> \[!NOTE]
> Рабочие процессы, активированные Dependabot запросы на вытягивание, обрабатываются так же, как если бы они были из вилированного репозитория, а также подвергаются этим ограничениям.
## `pull_request_review_comment`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------------------------------------------- | ------------------------------------------ | ----------------------------------------------- | ------------------------------------------------------ |
| [`pull_request_review_comment`](/ru/webhooks/webhook-events-and-payloads#pull_request_review_comment) | - `created`
- `edited`
- `deleted` | Последняя фиксация слияния в ветви `GITHUB_REF` | Ветвь слияния PR `refs/pull/PULL_REQUEST_NUMBER/merge` |
> \[!NOTE]
> Это событие активируется несколькими типами действий. Для информации о каждом типе активности см. [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#pull_request_review_comment). По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
Это событие запускает рабочий процесс при изменении комментария к проверке запроса на вытягивание. Комментарий к проверке запроса на вытягивание — это комментарий к разнице запроса на вытягивание. Для действий, связанных с проверкой запросов на вытягивание или комментариями к запросам, используйте событие [`pull_request_review`](#pull_request_review) или [`issue_comment`](#issue_comment). Сведения об API-интерфейсах комментариев проверка запроса на вытягивание см\[. в документации по API GraphQL или [Запросы на слияние](/ru/graphql/reference/pulls#object-pullrequestreviewcomment)]\(/rest/pulls#comments).
Например, можно запустить рабочий процесс, если к комментарию к проверке запроса на вытягивание применен тип действия `created` или `deleted`.
```yaml
on:
pull_request_review_comment:
types: [created, deleted]
```
#### Рабочие процессы в вилках репозиториев
Рабочие процессы по умолчанию не выполняются в вилках репозиториев. Вы должны включить GitHub Actions на вкладке **Действия** в вилке репозитория.
За исключением `GITHUB_TOKEN`, секреты не передаются в средство выполнения при активации рабочего процесса из вилки репозитория. У `GITHUB_TOKEN` него есть разрешения только для чтения в запросах на вытягивание из вилки репозиториев. Дополнительные сведения см. в разделе [Использование GITHUB\_TOKEN для проверки подлинности в рабочих процессах](/ru/actions/security-guides/automatic-token-authentication).
#### События запросов на вытягивание для вилок репозиториев
Для запросов на вытягивание из вилированного репозитория в базовый репозиторий GitHub отправляет `pull_request`в базовый репозиторий , а `pull_request_review``issue_comment``pull_request_review_comment`также события , и `pull_request_target` события. В вилке репозитория никакие события запросов на вытягивание не происходят.
Когда новый участник отправляет запрос на вытягивание в общедоступный репозиторий, может потребоваться утверждение запущенных рабочих процессов в запросе на вытягивание ответственным лицом с правами на запись. Дополнительные сведения см. в разделе [Утверждение рабочих процессов выполняется из вилок](/ru/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks).
Запросы на вытягивание из вилированного репозитория в частный репозиторий выполняются только при включении рабочих процессов, см. в разделе [Управление настройками GitHub Actions для репозитория](/ru/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories).
> \[!NOTE]
> Рабочие процессы, активированные Dependabot запросы на вытягивание, обрабатываются так же, как если бы они были из вилированного репозитория, а также подвергаются этим ограничениям.
## `pull_request_target`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | ------------------ |
| | | | |
| [`pull_request`](/ru/webhooks/webhook-events-and-payloads#pull_request) | - `assigned`
- `unassigned`
- `labeled`
- `unlabeled`
- `opened`
- `edited`
- `closed`
- `reopened`
- `synchronize`
- `converted_to_draft`
- `locked`
- `unlocked`
- `enqueued`
- `dequeued`
- `milestoned`
- `demilestoned`
- `ready_for_review`
- `review_requested`
- `review_request_removed`
- `auto_merge_enabled`
- `auto_merge_disabled` | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
| | | | |
> \[!NOTE]
> Это событие активируется несколькими типами действий. Для информации о каждом типе активности см. [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#pull_request). По умолчанию рабочий процесс выполняется только в том случае, если для типа действия события `pull_request_target` указано `opened`, `synchronize` или `reopened`. Чтобы активировать рабочие процессы с помощью других типов действий, используйте ключевое слово `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
Это событие запускает рабочий процесс при выполнении действия по запросу на вытягивание в репозитории рабочего процесса. Например, если типы действий не указаны, рабочий процесс запускается при открытии или повторном открытии запроса на вытягивание либо при обновлении главной ветви запроса на вытягивание.
Это событие выполняется в контексте по умолчанию в репозитории, а не в контексте коммита слияния, как это происходит с `pull_request` событием. Это предотвращает выполнение небезопасного кода из заголовка запроса на вытягивание, который может изменить репозиторий или украсть все секреты, используемые в рабочем процессе. Это событие позволяет рабочему процессу создавать метки или комментарии к запросам на вытягивание из вилок. Не рекомендуется использовать это событие для сборки или выполнения кода из запроса на вытягивание.
Чтобы обеспечить безопасность репозитория, ветви с именами, которые соответствуют определенным шаблонам (например, похожими на SHA), могут не запускать рабочие процессы с событием `pull_request_target`.
> \[!WARNING]
> Выполнение ненадежного кода на триггере `pull_request_target` может привести к уязвимостям системы безопасности. Эти уязвимости включают в себя отравление кэша и предоставление непреднамеренного доступа к привилегиям записи или секретам. Чтобы узнать, как безопасно использовать этот триггер, см. [Безопасное использование pull\_request\_target](/ru/actions/reference/security/securely-using-pull_request_target). Для получения дополнительной информации о базовых рисках см. [Справочник по безопасному использованию](/ru/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout) и [Предотвращение запросов pwn](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) из GitHub Security Lab.
Например, можно запустить рабочий процесс, если к запросу на вытягивание применен тип действия `assigned`, `opened`, `synchronize` или `reopened`.
```yaml
on:
pull_request_target:
types: [assigned, opened, synchronize, reopened]
```
### `pull_request_target` Выполнение рабочего процесса на основе головы или базовая ветвь запроса на вытягивание
Используйте фильтр `branches` или `branches-ignore`, чтобы настроить запуск рабочего процесса только для запросов на вытягивание, предназначенных для конкретных ветвей. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore).
Например, этот рабочий процесс будет выполняться при открытии запроса на вытягивание, предназначенного для ветви, имя которой начинается с `releases/`:
```yaml
on:
pull_request_target:
types:
- opened
branches:
- 'releases/**'
```
> \[!NOTE]
> Если используется как фильтр `branches`, так и фильтр `paths`, рабочий процесс будет выполняться только при выполнении условий обоих фильтров. Например, следующий рабочий процесс будет выполняться только тогда, когда на ветке с названием : открывается pull-запрос, включающий изменение в JavaScript-файл (`.js`) на ветке, название которой начинается с `releases/`:
>
> ```yaml
> on:
> pull_request_target:
> types:
> - opened
> branches:
> - 'releases/**'
> paths:
> - '**.js'
> ```
Чтобы выполнить задание на основе имени главной ветви запроса на вытягивание (в отличие от имени базовой ветви запроса на вытягивание), используйте контекст `github.head_ref` в условном режиме. Например, этот рабочий процесс будет выполняться при каждом открытии запроса на вытягивание, но задание `run_if` будет выполняться только в том случае, если заголовок запроса на вытягивание является ветвью, имя которой начинается с `releases/`:
```yaml
on:
pull_request_target:
types:
- opened
jobs:
run_if:
if: startsWith(github.head_ref, 'releases/')
runs-on: ubuntu-latest
steps:
- run: echo "The head of this PR starts with 'releases/'"
```
### `pull_request_target` Выполнение рабочего процесса на основе файлов, измененных в запросе на вытягивание
Используя фильтр `paths` или `paths-ignore`, можно настроить рабочий процесс таким образом, чтобы он выполнялся при изменении определенных файлов в запросе на вытягивание. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore).
Например, этот рабочий процесс будет выполняться, когда в запросе на вытягивание изменен файл JavaScript (`.js`):
```yaml
on:
pull_request_target:
paths:
- '**.js'
```
> \[!NOTE]
> Если используется как фильтр `branches`, так и фильтр `paths`, рабочий процесс будет выполняться только при выполнении условий обоих фильтров. Например, следующий рабочий процесс будет выполняться только тогда, когда на ветке с названием : открывается pull-запрос, включающий изменение в JavaScript-файл (`.js`) на ветке, название которой начинается с `releases/`:
>
> ```yaml
> on:
> pull_request_target:
> types:
> - opened
> branches:
> - 'releases/**'
> paths:
> - '**.js'
> ```
### `pull_request_target` Выполнение рабочего процесса при слиянии запроса на вытягивание
При слиянии запрос на вытягивание автоматически закрывается. Чтобы запустить рабочий процесс при слиянии запроса на вытягивание, используйте тип события `pull_request_target``closed` вместе с условием, проверяющим значение `merged` события. Например, следующий рабочий процесс будет выполняться при закрытии запроса на вытягивание. Задание `if_merged` будет выполняться только в том случае, если произошло слияние запроса на вытягивание.
```yaml
on:
pull_request_target:
types:
- closed
jobs:
if_merged:
if: github.event.pull_request.merged == true
runs-on: ubuntu-latest
steps:
- run: |
echo The PR was merged
```
## `push`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |
| [`push`](/ru/webhooks/webhook-events-and-payloads#push) | Нет данных | Фиксация подсказки, отправленная в ссылку. При удалении ветви SHA в выполнении рабочего процесса (и связанных ссылок) возвращается к ветвь по умолчанию репозитория. | Обновленная ссылка |
> \[!NOTE]
>
> * Полезная нагрузка webhook, доступная GitHub Actions, не включает атрибуты `added`, `removed` и `modified` в объекте `commit`. Полный объект фиксации можно получить с помощью API. Дополнительные сведения см. в документации \[по API GraphQL или [Коммиты](/ru/graphql/reference/commits#object-commit)]\(/rest/commits#get-a-commit).
> * События не будут создаваться, если одновременно продвигается более 5 000 филиалов. События не будут создаваться для тегов, если одновременно запускается более трёх тегов.
Запускает рабочий процесс при отправке фиксации или тега или при создании репозитория из шаблона. Это включает рабочие процессы, которые не объединены в стандартную ветку. Дополнительные сведения см. в разделе [События, инициирующие рабочие процессы](/ru/actions/reference/workflows-and-actions/events-that-trigger-workflows#running-your-workflow-only-when-a-push-to-specific-branches-occurs).
Например, можно запустить рабочий процесс при возникновении события `push`.
```yaml
on:
push
```
> \[!NOTE]
> `push` Когда событие веб-перехватчика активирует выполнение рабочего процесса, в поле "Действия" пользовательского интерфейса действий отображается учетная запись push-средства, а не автор или фиксация. Однако если изменения отправляются в репозиторий с помощью проверки подлинности SSH с ключом развертывания, то в поле "Кем отправлено" будет указан администратор репозитория, который проверил ключ развертывания при добавлении в репозиторий.
### Запуск рабочего процесса только при отправке в определенные ветви
Используйте фильтр `branches` или `branches-ignore`, чтобы настроить запуск рабочего процесса только при отправке в определенные ветви. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onpushbranchestagsbranches-ignoretags-ignore).
Например, этот рабочий процесс будет выполняться при отправке в ветвь `main` или в ветвь, имя которой начинается с `releases/`.
```yaml
on:
push:
branches:
- 'main'
- 'releases/**'
```
> \[!NOTE]
> Если используется как фильтр `branches`, так и фильтр `paths`, рабочий процесс будет выполняться только при выполнении условий обоих фильтров. Например, следующий рабочий процесс будет выполняться только тогда, когда push, включающий изменение в JavaScript-файл (`.js`) в ветку, название которой начинается с `releases/`:
>
> ```yaml
> on:
> push:
> branches:
> - 'releases/**'
> paths:
> - '**.js'
> ```
### Запуск рабочего процесса только при отправке определенных тегов
Используйте фильтр `tags` или `tags-ignore`, чтобы настроить запуск рабочего процесса только при отправке определенных тегов. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onpushbranchestagsbranches-ignoretags-ignore).
Например, этот рабочий процесс будет выполняться при отправке тега, имя которого начинается с `v1.`.
```yaml
on:
push:
tags:
- v1.**
```
### Запуск рабочего процесса только в случаях, когда отправка влияет на определенные файлы
Используя фильтр `paths` или `paths-ignore`, можно настроить рабочий процесс таким образом, чтобы он выполнялся только тогда, когда отправка затрагивает определенные файлы. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore).
Например, этот рабочий процесс будет выполняться при отправке изменений в файл JavaScript (`.js`):
```yaml
on:
push:
paths:
- '**.js'
```
## `registry_package`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------------------------------------- | ----------------------------- | ------------------------------- | ------------------------------------ |
| [`registry_package`](/ru/webhooks/webhook-events-and-payloads#package) | - `published`
- `updated` | Фиксация опубликованного пакета | Ветвь или тег опубликованного пакета |
> \[!NOTE]
> \*
> Это событие активируется несколькими типами действий. Для информации о каждом типе активности см. [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#registry_package). По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
> * При отправке образов контейнеров с несколькими архитектурами это событие происходит один раз на манифест, поэтому вы можете наблюдать за выполнением рабочего процесса несколько раз. Чтобы устранить эту проблему, и выполните задание рабочего процесса только для события, содержащего фактические сведения тега изображения, используйте условный код:
>
> ```yaml
> jobs:
> job_name:
> if: $true
> ```
Запускает ваш рабочий процесс, когда активность, связанная с GitHub Packages ним, происходит в вашем репозитории. Для получения дополнительной информации см. [GitHub Packages раздел Документация](/ru/packages).
Например, можно запустить рабочий процесс, если к новой версии пакета было применено действие `published`.
```yaml
on:
registry_package:
types: [published]
```
## `release`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | -------------------------------------------- |
| [`release`](/ru/webhooks/webhook-events-and-payloads#release) | - `published`
- `unpublished`
- `created`
- `edited`
- `deleted`
- `prereleased`
- `released` | Последняя фиксация в выпуске с тегами | Ссылка на тег выпуска `refs/tags/` |
> \[!NOTE]
> \*
> Это событие активируется несколькими типами действий. Для информации о каждом типе активности см. [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#release). По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Рабочие процессы не активируются для `created``edited`типов действий для проектов выпусков.`deleted` Когда вы создаёте релиз через GitHub интерфейс, ваш релиз может быть автоматически сохранен как черновик.
> * Тип `prereleased` не будет активироваться для предварительно опубликованных выпусков из черновых выпусков, но `published` тип будет активироваться. Если требуется, чтобы рабочий процесс выполнялся при стабильной *и* предварительной публикации, подпишитесь на тип действия `published` вместо `released` и `prereleased`.
Это событие запускает рабочий процесс при выполнении действия выпуска в репозитории. Сведения об API выпуска см\[. в документации по API GraphQL или [Релизы](/ru/graphql/reference/releases#object-release)]\(/rest/releases) в документации по REST API.
Например, можно запустить рабочий процесс, если к выпуску было применено действие `published`.
```yaml
on:
release:
types: [published]
```
## `repository_dispatch`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------ | ---------------- | --------------------------------------- | ------------------ |
| [repository\_dispatch](/ru/webhooks/webhook-events-and-payloads#repository_dispatch) | Пользовательское | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
Вы можете использовать GitHub API, чтобы запустить событие webhook, вызываемое [`repository_dispatch`](/ru/webhooks/webhook-events-and-payloads#repository_dispatch) при запуске рабочего процесса для активности, происходящей вне GitHub. Дополнительные сведения см. в разделе [Конечные точки REST API для репозиториев](/ru/rest/repos/repos#create-a-repository-dispatch-event).
При запросе на создание события `repository_dispatch` необходимо указать `event_type` в качестве описания типа действия. По умолчанию все `repository_dispatch` типы действий запускают рабочий процесс. Используйте ключевое слово `types`, чтобы ограничить выполнение рабочего процесса при отправке определенного значения `event_type` в полезные данные веб-перехватчика `repository_dispatch`.
```yaml
on:
repository_dispatch:
types: [test_result]
```
> \[!NOTE]
> Значение `event_type` ограничено 100 символами.
Все данные, которые отправляются с помощью параметра `client_payload`, доступны в контексте `github.event` рабочего процесса. Например, если отправить этот текст запроса при создании события диспетчеризации репозитория:
```json
{
"event_type": "test_result",
"client_payload": {
"passed": false,
"message": "Error: timeout"
}
}
```
можно получить доступ к полезным данным в рабочем процессе следующим образом:
```yaml
on:
repository_dispatch:
types: [test_result]
jobs:
run_if_failure:
if: ${{ !github.event.client_payload.passed }}
runs-on: ubuntu-latest
steps:
- env:
MESSAGE: ${{ github.event.client_payload.message }}
run: echo $MESSAGE
```
> \[!NOTE]
>
> * Максимальное число свойств верхнего уровня в `client_payload` 10.
> * Полезные данные могут содержать не более 65 535 символов.
## `schedule`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ---------------------------------------- | ------------- | --------------------------------------- | ------------------ |
| Нет данных | Нет данных | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
>
> * Событие `schedule` может быть отложено в периоды высокой нагрузки рабочих процессов GitHub Actions. К периодам высокой загрузки относится начало каждого часа. Если загрузка достаточно высока, некоторые задания в очереди могут быть удалены. Чтобы уменьшить вероятность задержки, запланируйте выполнение рабочего процесса в другое время часа.
> * Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
> * Запланированные рабочие процессы будут выполняться только в ветвь по умолчанию.
> * В общедоступном репозитории запланированные рабочие процессы автоматически отключаются, если в течение 60 дней не происходило никаких действий в репозитории. Сведения о повторном включении отключенного рабочего процесса см. в разделе [Отключение и включение рабочего процесса](/ru/actions/how-tos/manage-workflow-runs/disable-and-enable-workflows#enabling-a-workflow).
Событие `schedule` позволяет активировать рабочий процесс в запланированное время.
**Example:**
```yaml
on:
schedule:
- cron: "15 4,5 * * *"
```
Используйте [синтаксис POSIX cron](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07) для планирования рабочих процессов в определённое время. По умолчанию запланированные рабочие процессы работают в UTC. Вы можете опционально указать часовой пояс с помощью [строки часового пояса IANA](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) , чтобы планировать с учётом часового пояса. Запланированные рабочие процессы выполняются в последней фиксации на ветвь по умолчанию. Самый короткий интервал, с которым можно запускать запланированные рабочие процессы — 5 минут.
> \[!NOTE]
> Для расписаний, установленных `timezone` на часовой пояс, соблюдающий летнее время (DST), во время переходов на летнее время расписание в пропущенные часы перемещаются до следующего действительного времени. Например, расписание на 2:30 ночи переносится на 3:00 ночи.
Синтаксис Cron содержит пять полей, разделенных пробелом, где каждое поле представляет единицу времени.
```text
┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)
│ │ │ │ │
* * * * *
```
Эти операторы можно использовать в любом из пяти полей:
| Operator | Description | Пример |
| ------------------------------------------------------------------------------------------------------ | --------------------------- | ------ |
| \* | Любое значение | |
| `15 * * * *` запускается в каждую 15-ю минуту каждого часа каждого дня. | | |
| , | Разделитель списка значений | |
| `2,10 4,5 * * *` запускается во 2-ю и 10-ю минуты каждого 4-го и 5-го часов каждого дня. | | |
| - | Диапазон значений | |
| `30 4-6 * * *` запускается в 30-ю минуту каждого 4-го, 5-го и 6-го часов. | | |
| / | Значения шага | |
| `20/15 * * * *` запускается каждые 15 минут с 20-й по 59-ю минуту (в каждую 20-ю, 35-ю и 50-ю минуты). | | |
В этом примере рабочий процесс запускается в 5:30 утра в часовом поясе America/New\_York каждый понедельник по пятницу:
```yaml
on:
schedule:
- cron: '30 5 * * 1-5'
timezone: "America/New_York"
```
Один рабочий процесс может запускаться несколькими событиями `schedule`. Доступ к событию `schedule` , активировав рабочему процессу через `github.event.schedule` контекст. В этом примере рабочий процесс запускается в 5:30 UTC каждый понедельник-четверг и 17:30 UTC во вторник и четверг, но пропускает `Not on Monday or Wednesday` шаг в понедельник и среду.
```yaml
on:
schedule:
- cron: '30 5 * * 1,3'
- cron: '30 5,17 * * 2,4'
jobs:
test_schedule:
runs-on: ubuntu-latest
steps:
- name: Not on Monday or Wednesday
if: github.event.schedule != '30 5 * * 1,3'
run: echo "This step will be skipped on Monday and Wednesday"
- name: Every time
run: echo "This step will always run"
```
> \[!NOTE]
> GitHub Actionsне поддерживает нестандартный синтаксис `@yearly`, `@monthly`, `@weekly``@daily``@hourly`и .`@reboot`
Используйте редактор [crontab guru](https://crontab.guru/), чтобы создавать синтаксис cron и подтверждать время его выполнения. Начать работу можно со списка [примеров crontab guru](https://crontab.guru/examples.html).
### `actor` для запланированных рабочих процессов
Некоторые события репозитория изменяют связанный `actor` с рабочим процессом. Например, пользователь, который изменяет ветвь по умолчанию репозитория, который изменяет ветвь, в которой выполняются запланированные рабочие процессы, становится `actor` для запланированных рабочих процессов.
Для деактивированного запланированного рабочего процесса, если пользователь с `write` разрешениями на репозиторий делает фиксацию, которая изменяет `cron` расписание рабочего процесса, рабочий процесс будет повторно активирован, и этот пользователь станет связанным с любым рабочим процессом `actor` .
Уведомления о запланированных рабочих процессах отправляются пользователю, который внес последние изменения в синтаксис cron файла рабочего процесса. Дополнительные сведения см. в разделе [Уведомления о выполнении рабочих процессов](/ru/actions/concepts/workflows-and-actions/notifications-for-workflow-runs).
> \[!NOTE]
> Для предприятия с Enterprise Managed Users, запуск запланированного рабочего процесса требует, чтобы статус пользовательской учётной записи, `actor` связанной с рабочим процессом, был активен в данный момент (то есть не приостановлен и не удалён).
>
> * Запланированные рабочие процессы не будут выполняться, если последний `actor` связанный с запланированным рабочим процессом был удален Enterprise Managed User поставщиком идентификации (IdP). Однако если последний `actor`Enterprise Managed User не был депровизирован IdP и был удалён только как участник из определённой организации в предприятии, запланированные рабочие процессы всё равно будут выполняться с этим пользовательским заданием как `actor`.
> * Аналогично, для предприятия без Enterprise Managed Users, удаление пользователя из организации не мешает запланированным рабочим процессам, в которых был этот `actor` пользователь.
> * Таким образом, важен статус *учетной записи* пользователя как Enterprise Managed User в обеих случаях, так и в не-сценарияхEnterprise Managed User , *а не\_\_статус членства* пользователя в организации, где находится запланированный рабочий процесс.
## `status`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------- | ------------- | --------------------------------------- | ------------------ |
| [`status`](/ru/webhooks/webhook-events-and-payloads#status) | Нет данных | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
Это событие запускает рабочий процесс при изменении состояния фиксации Git. Фиксации могут быть помечены как `error`, `failure`, `pending` или `success`. Чтобы предоставить дополнительные сведения об изменении состояния, может потребоваться использовать событие [`check_run`](#check_run). Сведения об API-интерфейсах состояния фиксации см\[. в документации по API GraphQL или [Коммиты](/ru/graphql/reference/commits#object-status)]\(/rest/commits#commit-statuses).
Например, можно запустить рабочий процесс при возникновении события `status`.
```yaml
on:
status
```
Чтобы запустить задание в рабочем процессе на основе нового состояния фиксации, можно использовать контекст `github.event.state`. Например, следующий рабочий процесс активируется при изменении состояния фиксации, но задание `if_error_or_failure` выполняется только в том случае, если новое состояние фиксации — `error` или `failure`.
```yaml
on:
status
jobs:
if_error_or_failure:
runs-on: ubuntu-latest
if: >-
github.event.state == 'error' ||
github.event.state == 'failure'
steps:
- env:
DESCRIPTION: ${{ github.event.description }}
run: |
echo The status is error or failed: $DESCRIPTION
```
## `watch`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------------------------- | ------------- | --------------------------------------- | ------------------ |
| [`watch`](/ru/webhooks/webhook-events-and-payloads#watch) | - `started` | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> \*
> Это событие активируется несколькими типами действий. Хотя поддерживается только `started` тип активности, указание типа активности сохранит ваш рабочий процесс специфическим при добавлении новых типов активности в будущем. Сведения о каждом типе действия см. в разделе [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#watch). По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
Это событие запускает рабочий процесс, когда репозиторий рабочего процесса добавляется в избранное. Сведения об API запроса на вытягивание см\[. в документации по API GraphQL или [Activity](/ru/graphql/reference/activity#mutation-addstar)]\(/rest/activity/starring).
Например, можно запустить рабочий процесс при добавлении в избранное репозитория, который является типом действия `started` для события наблюдения.
```yaml
on:
watch:
types: [started]
```
## `workflow_call`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------ | ------------- | ------------------------------------------------ | ------------------------------------------------ |
| То же, что и рабочий процесс вызывающего объекта | Нет данных | То же, что и рабочий процесс вызывающего объекта | То же, что и рабочий процесс вызывающего объекта |
`workflow_call` используется для того, чтобы указать, что рабочий процесс может вызываться другим рабочим процессом. Когда рабочий процесс активируется с помощью события `workflow_call`, полезные данные события в вызываемом рабочем процессе идентичны полезным данным событий вызывающего рабочего процесса. Дополнительные сведения см. в разделе [Повторное использование рабочих процессов](/ru/actions/how-tos/reuse-automations/reuse-workflows).
В приведенном ниже примере рабочий процесс запускается только при вызове из другого рабочего процесса:
```yaml
on: workflow_call
```
## `workflow_dispatch`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------------------------------- | ------------- | ------------------------------------------------ | ---------------------------------- |
| [workflow\_dispatch](/ru/webhooks/webhook-events-and-payloads#workflow_dispatch) | Нет данных | Последняя фиксация в ветви или теге `GITHUB_REF` | Ветвь или тег, получающий отправку |
> \[!NOTE]
> Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
Чтобы включить активацию рабочего процесса вручную, необходимо настроить `workflow_dispatch` событие. Вы можете вручную запустить рабочий процесс через GitHub API GitHub CLIили интерфейс GitHub . Дополнительные сведения см. в разделе [Запуск рабочего процесса вручную](/ru/actions/how-tos/manage-workflow-runs/manually-run-a-workflow).
```yaml
on: workflow_dispatch
```
### Предоставление входных данных
Вы можете настроить пользовательские свойства входа, входные значения по умолчанию и необходимые входные данные для события непосредственно в рабочем процессе. При активации события можно указать ссылку `ref` и любые данные `inputs`. При запуске рабочего процесса доступ к входным значениям можно получить в контексте `inputs`. Дополнительные сведения см. в разделе [Справочник по контекстам](/ru/actions/reference/workflows-and-actions/contexts).
> \[!NOTE]
>
> * Рабочий процесс также получит входные данные в контексте `github.event.inputs` . Информация в контексте `inputs` и в контексте `github.event.inputs` идентична, за исключением того, что контекст `inputs` сохраняет логические значения в исходном формате логических значений, не преобразовывая их в строки. Тип `choice` разрешается в строку и является одним вариантом выбора.
> * Максимальное количество свойств верхнего уровня для `inputs` — 25 .
> * Максимальная полезная нагрузка составляет `inputs` 65 535 символов.
В этом примере определяются входные данные, называемые `logLevel`, `tags`и `environment`. Значения этих входных данных передаются рабочему процессу при его запуске. Затем этот рабочий процесс выводит значения в журнал, используя свойства контекста `inputs.logLevel`и `inputs.tags` ,`inputs.environment`.
```yaml
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'
type: choice
options:
- info
- warning
- debug
tags:
description: 'Test scenario tags'
required: false
type: boolean
environment:
description: 'Environment to run tests against'
type: environment
required: true
jobs:
log-the-inputs:
runs-on: ubuntu-latest
steps:
- run: |
echo "Log level: $LEVEL"
echo "Tags: $TAGS"
echo "Environment: $ENVIRONMENT"
env:
LEVEL: ${{ inputs.logLevel }}
TAGS: ${{ inputs.tags }}
ENVIRONMENT: ${{ inputs.environment }}
```
При запуске этого рабочего процесса из браузера необходимо сначала ввести значения необходимых входных данных вручную.
Вы также можете передавать вводные данные при запуске рабочего процесса из скрипта или с помощью GitHub CLI. Например:
```shell
gh workflow run run-tests.yml -f logLevel=warning -f tags=false -f environment=staging
```
Для получения дополнительной информации смотрите GitHub CLI информацию в [разделе AUTOTITLE.](/ru/actions/how-tos/manage-workflow-runs/manually-run-a-workflow)
## `workflow_run`
| Полезные данные события веб-перехватчика | Типы действий | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------------- | --------------------------------------------------- | --------------------------------------- | ------------------ |
| [`workflow_run`](/ru/webhooks/webhook-events-and-payloads#workflow_run) | - `completed`
- `requested`
- `in_progress` | Последняя фиксация в ветви по умолчанию | Ветвь по умолчанию |
> \[!NOTE]
> \*
> Это событие активируется несколькими типами действий.
> `requested` Тип активности не возникает при повторном запуске рабочего процесса. Сведения о каждом типе действия см. в разделе [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads#workflow_run). По умолчанию все типы действий активируют рабочие процессы, которые выполняются в этом событии. Вы можете ограничить запуск рабочего процесса определенными типами действий с помощью ключевого слова `types`. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes).
>
> * Это событие запускается только в том случае, если файл рабочего процесса существует в ветвь по умолчанию.
> * Вы не можете использовать `workflow_run` для объединения более трех уровней рабочих процессов. Например, при попытке последовательно запустить пять рабочих процессов (от `B` до `F`) после запуска начального рабочего процесса `A` (т. е. `A` → `B` → `C` → `D` → `E` → `F`) рабочие процессы `E` и `F` не будут выполняться.
Это событие возникает при запросе или завершении запуска рабочего процесса. Оно позволяет выполнить рабочий процесс после выполнения или завершения другого рабочего процесса. Рабочий процесс, запущенный событием `workflow_run`, может получать доступ к секретам и записывать токены, даже если предыдущий рабочий процесс не имел таких разрешений. Это полезно в случаях, когда предыдущему рабочему процессу намеренно не предоставлены привилегии, но в дальнейшем необходимо выполнить привилегированное действие.
> \[!WARNING]
> Выполнение ненадежного кода на триггере `workflow_run` может привести к уязвимостям системы безопасности. Эти уязвимости включают в себя отравление кэша и предоставление непреднамеренного доступа к привилегиям записи или секретам. Дополнительные сведения см[](/ru/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout). в документации по GitHub Enterprise Cloud и [предотвращении запросов](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) pwn на веб-сайте GitHub Security Lab.
В этом примере запуск рабочего процесса выполняется после завершения отдельного рабочего процесса Run Tests.
```yaml
on:
workflow_run:
workflows: [Run Tests]
types:
- completed
```
При указании нескольких процессов `workflows` для события `workflow_run` необходимо запустить только один из этих рабочих процессов. Например, рабочий процесс со следующим триггером будет запускаться после завершения рабочего процесса Staging или Lab.
```yaml
on:
workflow_run:
workflows: [Staging, Lab]
types:
- completed
```
### Запуск рабочего процесса на основе результатов другого рабочего процесса
Запуск рабочего процесса выполняется независимо от результатов предыдущего рабочего процесса. Чтобы запустить задание или шаг на основе результата запуска рабочего процесса, можно использовать условие со свойством `github.event.workflow_run.conclusion`. Например, этот рабочий процесс будет выполняться всякий раз, когда завершается рабочий процесс Build, однако задание `on-success` будет выполняться только в случае, если рабочий процесс Build выполнен успешно, а задание `on-failure` будет выполняться только в случае, если рабочий процесс Build завершился ошибкой:
```yaml
on:
workflow_run:
workflows: [Build]
types: [completed]
jobs:
on-success:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'success' }}
steps:
- run: echo 'The triggering workflow passed'
on-failure:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'failure' }}
steps:
- run: echo 'The triggering workflow failed'
```
### Ограничение запуска рабочего процесса на основе ветвей
Используйте фильтр `branches` или `branches-ignore`, чтобы указать, в каких ветвях должен выполняться рабочий процесс, чтобы активировать его. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_runbranchesbranches-ignore). Например, рабочий процесс со следующим триггером будет выполняться только в случае, если рабочий процесс с именем `Build` выполняется в ветви с именем `canary`.
```yaml
on:
workflow_run:
workflows: [Build]
types: [requested]
branches: [canary]
```
### Использование данных из рабочего процесса, активирующего триггер
Можно получить доступ к [`workflow_run` полезным данным события](/ru/webhooks/webhook-events-and-payloads#workflow_run), которые относятся к рабочему процессу, активирующему триггер для запуска рабочего процесса. Например, если рабочий процесс, активирующий триггер, создает артефакты, рабочий процесс, который активируется событием `workflow_run`, может получить доступ к этим артефактам.
Следующий рабочий процесс передает данные в виде артефакта. (Это упрощенный пример, где в качестве данных выступает номер запроса на вытягивание.)
```yaml
name: Upload data
on:
pull_request:
jobs:
upload:
runs-on: ubuntu-latest
steps:
- name: Save PR number
env:
PR_NUMBER: ${{ github.event.number }}
run: |
mkdir -p ./pr
echo $PR_NUMBER > ./pr/pr_number
- uses: actions/upload-artifact@v4
with:
name: pr_number
path: pr/
```
После завершения указанного выше рабочего процесса запускается следующий рабочий процесс. Следующий рабочий процесс использует `github.event.workflow_run` контекст и действие actions/download-artifact\@v5 для загрузки артефакта, загруженного вышеуказанным рабочим процессом, а затем комментирует pull request, номер которого был загружен как артефакт.
```yaml
name: Use the data
on:
workflow_run:
workflows: [Upload data]
types:
- completed
jobs:
download:
runs-on: ubuntu-latest
steps:
- name: 'Download artifact'
uses: actions/download-artifact@v5
with:
name: pr_number
# do not extract in the workspace dir that may contain executable scripts
path: ${{ runner.temp }}/artifacts
run-id: ${{ github.event.workflow_run.id }}
github-token: ${{ secrets.GITHUB_TOKEN }}
- name: 'Comment on PR'
uses: actions/github-script@v8
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
const fs = require('fs');
const path = require('path');
const temp = '${{ runner.temp }}/artifacts';
const issue_number_raw = fs.readFileSync(path.join(temp, 'pr_number'), 'utf8').trim();
const issue_number = Number(issue_number_raw);
if (!Number.isInteger(issue_number)) {
throw new Error(`Invalid PR number in pr_number artifact: "${issue_number_raw}"`);
}
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: issue_number,
body: 'Thank you for the PR!'
});
```