{"meta":{"title":"Активация рабочего процесса","intro":"Как автоматически запустить GitHub Actions рабочие процессы","product":"GitHub Actions","breadcrumbs":[{"href":"/ru/actions","title":"GitHub Actions"},{"href":"/ru/actions/how-tos","title":"Инструкции"},{"href":"/ru/actions/how-tos/write-workflows","title":"Написание рабочих процессов"},{"href":"/ru/actions/how-tos/write-workflows/choose-when-workflows-run","title":"Выбор времени выполнения рабочих процессов"},{"href":"/ru/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow","title":"Запуск рабочего процесса"}],"documentType":"article"},"body":"# Активация рабочего процесса\n\nКак автоматически запустить GitHub Actions рабочие процессы\n\n## Необходимые компоненты\n\nДополнительные сведения о рабочих процессах и активации рабочих процессов см. в разделе [Рабочие процессы](/ru/actions/concepts/workflows-and-actions/workflows).\n\n## Активация рабочего процесса из рабочего процесса\n\nКогда вы используете репозитории `GITHUB_TOKEN` для выполнения задач, события, вызванные ими, `GITHUB_TOKEN` не создадут новый рабочий процесс, за следующими исключениями:\n\n* `workflow_dispatch` А `repository_dispatch` события всегда создают запуски рабочих процессов.\n* `pull_request`события с , или типами активности: когда рабочий процесс с `GITHUB_TOKEN` использованием pull-запроса создаёт или обновляется, возникающее `pull_request` событие создаёт рабочий процесс в **состоянии, требуемом одобрения**.`reopened``synchronize``opened` Pull-запрос отображает баннер в окне слияния, и пользователь с доступом к записи в репозиторий может начать запуски, выбрав **Approve workflows для запуска**. Другие `pull_request` типы активности (такие как `labeled`, `edited`, или `closed`) не создают запуски рабочих процессов. Это предотвращает рекурсивные запуски рабочих процессов, при этом позволяя CI-рабочим процессам запускаться на пулл-запросах, созданных автоматизацией. Для получения дополнительной информации об одобрении запусков рабочих процессов см. [Утверждение рабочих процессов выполняется из вилок](/ru/actions/how-tos/manage-workflow-runs/approve-runs-from-forks).\n\nДля всех остальных событий это поведение предотвращает случайное создание рекурсивных рабочих процессов. Например, если при запуске рабочего процесса выполняется передача кода с помощью `GITHUB_TOKEN` репозитория, новый рабочий процесс не будет запущен, даже если репозиторий содержит рабочий процесс, настроенный для запуска при наступлении события `push`. Для получения дополнительной информации см. [Использование GITHUB\\_TOKEN для проверки подлинности в рабочих процессах](/ru/actions/tutorials/authenticate-with-github_token).\n\nЕсли вы хотите запустить рабочий процесс внутри запуска рабочего процесса, можно использовать GitHub App токен доступа установки или personal access token вместо `GITHUB_TOKEN` него для запуска событий, требующих токена. Использование одной из этих альтернатив также позволяет `pull_request` рабочим процессам запускаться автоматически (без описанного выше запроса одобрения) при создании или обновлении pull request с помощью автоматизации.\n\nЕсли вы используете GitHub App, вам нужно создать GitHub App и хранить ID приложения и приватный ключ как секреты. Дополнительные сведения см. в разделе [Создание аутентифицированных запросов API с помощью приложения GitHub в рабочем процессе GitHub Actions](/ru/apps/creating-github-apps/authenticating-with-a-github-app/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow). Если вы используете personal access token, вам нужно создать и personal access token хранить его как секрет. Для получения дополнительной информации о создании personal access token, см. [Управление личными маркерами доступа](/ru/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens). Дополнительные сведения о хранении секретов см. в разделе [Использование секретов в GitHub Actions](/ru/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets).\n\nЧтобы минимизировать GitHub Actions затраты на использование, убедитесь, что вы не создаёте рекурсивных или непреднамеренных рабочих процессов.\n\nНапример, следующий рабочий процесс использует personal access token (хранящийся как секрет под названием `MY_TOKEN`) для добавления метки к проблеме с помощью GitHub CLI. Все рабочие процессы, выполняемые при добавлении метки, будут выполняться после выполнения этого шага.\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n\njobs:\n  label_issue:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          GH_TOKEN: ${{ secrets.MY_TOKEN }}\n          ISSUE_URL: ${{ github.event.issue.html_url }}\n        run: |\n          gh issue edit $ISSUE_URL --add-label \"triage\"\n```\n\nИ наоборот, следующий рабочий процесс использует `GITHUB_TOKEN` для добавления метки в проблему. При добавлении метки рабочие процессы не будут запускаться.\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n\njobs:\n  label_issue:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n          ISSUE_URL: ${{ github.event.issue.html_url }}\n        run: |\n          gh issue edit $ISSUE_URL --add-label \"triage\"\n```\n\n## Использование событий для активации рабочих процессов\n\nИспользуйте ключ `on`, чтобы указать, какие события активируют рабочий процесс. Дополнительные сведения о событиях, которые можно использовать, см. в разделе [События, инициирующие рабочие процессы](/ru/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\n### Использование одного события\n\nНапример, рабочий процесс со следующим значением `on` будет выполняться при осуществлении отправки в любую ветвь в репозитории рабочего процесса:\n\n```yaml\non: push\n```\n\n### Использование нескольких событий\n\nМожно указать одно или несколько событий. Например, рабочий процесс со следующим значением `on` будет выполняться при осуществлении отправки в любую ветвь в репозитории, или когда кто-то создает вилку репозитория:\n\n```yaml\non: [push, fork]\n```\n\nЕсли указано несколько событий, для активации рабочего процесса необходимо, чтобы произошло только одно из них. Если одновременно происходят несколько событий, активирующих рабочий процесс, будет активировано несколько выполнений рабочих процессов.\n\n### Использование типов действий и фильтров с несколькими событиями\n\nДля дальнейшего управления выполнением рабочего процесса можно использовать типы действий и фильтры. Дополнительные сведения см. в разделах [Использование типов действий событий](#using-event-activity-types) и [Использование фильтров](#using-filters). Если вы указываете типы действий или фильтры для события и триггеры рабочего процесса для нескольких событий, необходимо настроить каждое событие отдельно. Необходимо добавить двоеточие (`:`) ко всем событиям, включая события без конфигурации.\n\nНапример, рабочий процесс со следующим значением `on` будет выполняться в следующих случаях:\n\n* создание метки;\n* отправка в ветвь `main` в репозитории;\n* отправка в ветвь с поддержкой GitHub Pages.\n\n```yaml\non:\n  label:\n    types:\n      - created\n  push:\n    branches:\n      - main\n  page_build:\n```\n\n## Использование типов действий событий\n\nНекоторые события имеют типы действий, позволяющие лучше контролировать выполнение рабочего процесса. Используйте `on.<event_name>.types` для определения типа действия для события, которое активирует запуск рабочего процесса.\n\nНапример, событие `issue_comment` имеет типы действий `created`, `edited` и `deleted`. Если рабочий процесс активируется в событии `label`, он будет выполняться при создании, изменении или удалении метки. Если указать тип действия `created` для события `label`, рабочий процесс будет запускаться при создании метки, но не при изменении или удалении метки.\n\n```yaml\non:\n  label:\n    types:\n      - created\n```\n\nЕсли указать несколько типов действий, для активации рабочего процесса потребуется выполнить только один из этих типов действий. Если одновременно происходят несколько типов действий для событий, активирующих рабочий процесс, будет активировано несколько выполнений рабочих процессов. Например, следующий рабочий процесс активируется при открытии проблемы или добавлении для нее метки. Если открывается проблема с двумя метками, начинаются три запуска рабочего процесса: один для события открытия проблемы и два для двух событий проблем с метками.\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n      - labeled\n```\n\nДополнительные сведения о каждом событии и их типах действий см. в разделе [События, инициирующие рабочие процессы](/ru/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\n## Использование фильтров\n\nНекоторые события имеют фильтры, позволяющие лучше контролировать выполнение рабочего процесса.\n\nНапример, событие `push` имеет фильтр `branches`, из-за которого рабочий процесс выполняется только при отправке в ветвь, которая соответствует фильтру `branches`, а не при любой отправке.\n\n```yaml\non:\n  push:\n    branches:\n      - main\n      - 'releases/**'\n```\n\n### Использование фильтров для назначения определенных ветвей для событий запроса на вытягивание\n\nПри использовании событий `pull_request` и `pull_request_target` можно настроить выполнение рабочего процесса только для запросов на вытягивание, предназначенных для конкретных ветвей.\n\nИспользуйте фильтр `branches`, если требуется включить шаблоны имен ветвей или как включить, так и исключить их. Используйте фильтр `branches-ignore`, если требуется только исключить шаблоны имен ветвей. Для одного и того же события в рабочем процессе нельзя использовать фильтры `branches` и `branches-ignore` одновременно.\n\nЕсли вы определили и `branches`/`branches-ignore`, и [`paths`/`paths-ignore`](/ru/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore), рабочий процесс будет запускаться только в случае, если выполнены оба фильтра.\n\nКлючевые слова `branches` и `branches-ignore` принимают стандартные маски, использующие такие символы, как `*`, `**`, `+`, `?`, `!` и другие, чтобы соответствовать нескольким именам ветвей. Если имя содержит любой из этих символов и требуется буквальное совпадение, необходимо экранировать каждый из этих специальных символов с помощью `\\`. Дополнительные сведения о шаблонах глобов см. в [разделе AUTOTITLE](/ru/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\n#### Пример: включение ветвей\n\nШаблоны, определенные в `branches`, оцениваются по имени ссылки Git. Например, указанный ниже рабочий процесс будет выполняться всякий раз, когда происходит событие `pull_request` для запроса на вытягивание, нацеленного на:\n\n* ветви с именем `main` (`refs/heads/main`);\n* ветви с именем `mona/octocat` (`refs/heads/mona/octocat`);\n* ветви, имя которой начинается с `releases/`, например `releases/10` (`refs/heads/releases/10`);\n\n```yaml\non:\n  pull_request:\n    # Sequence of patterns matched against refs/heads\n    branches:\n      - main\n      - 'mona/octocat'\n      - 'releases/**'\n```\n\nЕсли рабочий процесс пропускается из-за фильтрации ветвей, [фильтрации](/ru/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore) путей или [сообщения](/ru/actions/how-tos/manage-workflow-runs/skip-workflow-runs) фиксации, то проверки, связанные с этим рабочим процессом, останутся в состоянии \"Ожидание\". Запрос на включение внесенных изменений, требующий успешной проверки, будет заблокирован при слиянии.\n\n#### Пример исключения ветвей\n\nВ случае соответствия шаблона `branches-ignore` рабочий процесс не будет выполняться. Шаблоны, определенные в `branches-ignore`, оцениваются по имени ссылки Git. Например, указанный ниже рабочий процесс будет выполняться всякий раз, когда происходит событие `pull_request`, если при этом запрос на вытягивание не нацелен на:\n\n* ветви с именем `mona/octocat` (`refs/heads/mona/octocat`);\n* ветви, имя которой соответствует `releases/**-alpha`, например `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`); <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  pull_request:\n    # Sequence of patterns matched against refs/heads\n    branches-ignore:\n      - 'mona/octocat'\n      - 'releases/**-alpha'\n```\n\n#### Пример: включение и исключение ветвей\n\nНельзя использовать `branches` и `branches-ignore` для фильтрации одного и того же события в одном рабочем процессе. Если вам нужно с помощью шаблонов одновременно включить и исключить имена ветвей для одного события, используйте фильтр `branches` с символом `!`, чтобы указать, какие ветви следует исключить.\n\nЕсли вы определяете ветвь с символом `!`, необходимо также определить по крайней мере одну ветвь без символа `!`. Если вы хотите только исключить ветви, используйте вместо этого `branches-ignore`.\n\nПорядок определения шаблонов имеет значение.\n\n* Соответствующий отрицательный шаблон (с префиксом `!`) после положительного совпадения исключает ссылку Git.\n* Соответствующий положительный шаблон после отрицательного совпадения снова включает ссылку Git.\n\nУказанный ниже рабочий процесс будет выполняться на событиях `pull_request` для запросов на вытягивание, нацеленных на `releases/10` или `releases/beta/mona`, но не для запросов на вытягивание, нацеленных на `releases/10-alpha` или `releases/beta/3-alpha`, потому что отрицательный шаблон `!releases/**-alpha` соответствует положительному шаблону. <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  pull_request:\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n### Использование фильтров для назначения определенных ветвей или тегов для событий отправки\n\nПри использовании события `push` можно настроить выполнение рабочего процесса в определенных ветвях или тегах.\n\nИспользуйте фильтр `branches`, если требуется включить шаблоны имен ветвей или как включить, так и исключить их. Используйте фильтр `branches-ignore`, если требуется только исключить шаблоны имен ветвей. Для одного и того же события в рабочем процессе нельзя использовать фильтры `branches` и `branches-ignore` одновременно.\n\nИспользуйте фильтр `tags`, если требуется включить шаблоны имен тегов или как включить, так и исключить их. Используйте фильтр `tags-ignore`, если требуется только исключить шаблоны имен тегов. Для одного и того же события в рабочем процессе нельзя использовать фильтры `tags` и `tags-ignore` одновременно.\n\nЕсли вы определяете только или `tags`/`tags-ignore`только`branches`/`branches-ignore`, рабочий процесс не будет выполняться для событий, влияющих на неопределенную ссылку на Git. Если определить ни одно `tags`/`tags-ignore` или`branches`/`branches-ignore`, рабочий процесс будет выполняться для событий, влияющих на ветви или теги. Если вы определили и `branches`/`branches-ignore`, и [`paths`/`paths-ignore`](/ru/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore), рабочий процесс будет запускаться только в случае, если выполнены оба фильтра.\n\nКлючевые слова `branches`, `branches-ignore`, `tags`и `tags-ignore` принимают стандартные маски, использующие такие символы, как `*`, `**`, `+`, `?`, `!` и другие, для сопоставления нескольких имен ветвей или тегов. Если имя содержит любой из этих символов, и требуется буквальное совпадение, необходимо *экранировать* каждый из этих специальных символов с помощью `\\`. Дополнительные сведения о шаблонах глобов см. в [разделе AUTOTITLE](/ru/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\n#### Пример. Включение ветвей и тегов\n\nШаблоны, определенные в `branches` и `tags`, применяются для имени ссылки Git. Например, следующий рабочий процесс будет выполняться всякий раз, когда событие `push` происходит в:\n\n* ветви с именем `main` (`refs/heads/main`);\n* ветви с именем `mona/octocat` (`refs/heads/mona/octocat`);\n* ветви, имя которой начинается с `releases/`, например `releases/10` (`refs/heads/releases/10`);\n* теге с именем `v2` (`refs/tags/v2`);\n* теге, имя которого начинается с `v1.`, например `v1.9.1` (`refs/tags/v1.9.1`).\n\n```yaml\non:\n  push:\n    # Sequence of patterns matched against refs/heads\n    branches:\n      - main\n      - 'mona/octocat'\n      - 'releases/**'\n    # Sequence of patterns matched against refs/tags\n    tags:\n      - v2\n      - v1.*\n```\n\n#### Пример. Исключение ветвей и тегов\n\nЕсли шаблон соответствует шаблону `branches-ignore` или `tags-ignore`, рабочий процесс не будет выполняться. Шаблоны, определенные в `branches` и `tags`, применяются для имени ссылки Git. Например, следующий рабочий процесс будет выполняться всякий раз, когда происходит событие `push`, если при этом не происходит событие `push` в:\n\n* ветви с именем `mona/octocat` (`refs/heads/mona/octocat`);\n* ветви, имя которой соответствует `releases/**-alpha`, например `releases/beta/3-alpha` (`refs/heads/releases/beta/3-alpha`); <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n* теге с именем `v2` (`refs/tags/v2`);\n* теге, имя которого начинается с `v1.`, например `v1.9` (`refs/tags/v1.9`).\n\n```yaml\non:\n  push:\n    # Sequence of patterns matched against refs/heads\n    branches-ignore:\n      - 'mona/octocat'\n      - 'releases/**-alpha'\n    # Sequence of patterns matched against refs/tags\n    tags-ignore:\n      - v2\n      - v1.*\n```\n\n#### Пример. Включение и исключение ветвей и тегов\n\nВы не можете использовать `branches` и `branches-ignore` для фильтрации одного и того же события в одном рабочем процессе. Аналогично, вы не можете использовать `tags` и `tags-ignore` для фильтрации одного и того же события в одном рабочем процессе. Если вы хотите одновременно включить и исключить шаблоны ветвей или тегов для одного события, используйте фильтр `branches` или `tags` с символом `!`, чтобы указать, какие ветви или теги следует исключить.\n\nЕсли вы определяете ветвь с символом `!`, необходимо также определить по крайней мере одну ветвь без символа `!`. Если вы хотите только исключить ветви, используйте вместо этого `branches-ignore`. Аналогично, если вы определяете тег с символом `!`, необходимо также определить по крайней мере один тег без символа `!`. Если вы хотите только исключить теги, используйте вместо этого `tags-ignore`.\n\nПорядок определения шаблонов имеет значение.\n\n* Соответствующий отрицательный шаблон (с префиксом `!`) после положительного совпадения исключает ссылку Git.\n* Соответствующий положительный шаблон после отрицательного совпадения снова включает ссылку Git.\n\nСледующий рабочий процесс будет выполняться при отправке в `releases/10` или `releases/beta/mona`, но не в `releases/10-alpha` или `releases/beta/3-alpha`, потому что за положительным шаблоном следует отрицательный шаблон `!releases/**-alpha`. <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  push:\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n### Использование фильтров для назначения определенных ветвей для запросов на вытягивание или событий отправки\n\nПри использовании событий `push` и `pull_request` можно настроить запускаемый рабочий процесс в зависимости от того, какие пути к файлам изменяются. Фильтры путей не оцениваются при отправке тегов.\n\nИспользуйте фильтр `paths`, если требуется включить шаблоны путей к файлам или одновременно включить и исключить их. Используйте фильтр `paths-ignore`, если требуется только исключить шаблоны путей к файлам. Для одного и того же события в рабочем процессе нельзя использовать фильтры `paths` и `paths-ignore` одновременно. Если вы хотите включить и исключить шаблоны путей для одного события, используйте `paths` префикс фильтра с `!` символом, чтобы указать, какие пути следует исключить.\n\n> \\[!NOTE]\n> Порядок определения `paths` шаблонов имеет значение:\n>\n> * Соответствующий отрицательный шаблон (с префиксом `!`) после положительного совпадения исключает путь.\n> * Соответствующий положительный шаблон после отрицательного совпадения снова включает путь.\n\nЕсли вы определили и `branches`/`branches-ignore`, и `paths`/`paths-ignore`, рабочий процесс будет запускаться только в случае, если выполнены оба фильтра.\n\nКлючевые слова `paths` и `paths-ignore` принимают стандартные маски, в которых для соответствия нескольким именам путей используются подстановочные знаки `*` и `**`. Дополнительные сведения см. в [разделе AUTOTITLE](/ru/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\n#### Пример. Включение путей\n\nЕсли хотя бы один путь соответствует шаблону в фильтре `paths`, рабочий процесс запускается. Например, приведенный ниже рабочий процесс будет выполняться при каждой отправке файла JavaScript (`.js`).\n\n```yaml\non:\n  push:\n    paths:\n      - '**.js'\n```\n\nЕсли рабочий процесс пропускается из-за фильтрации путей, [фильтрации](/ru/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore) ветвей или [сообщения](/ru/actions/how-tos/manage-workflow-runs/skip-workflow-runs) фиксации, то проверки, связанные с этим рабочим процессом, останутся в состоянии \"Ожидание\". Запрос на включение внесенных изменений, требующий успешной проверки, будет заблокирован при слиянии.\n\n#### Пример. Исключение путей\n\nЕсли все имена путей соответствуют шаблонам в `paths-ignore`, рабочий процесс не запускается. Если хотя бы одно имя пути не соответствует шаблонам в `paths-ignore`, рабочий процесс запускается.\n\nРабочий процесс с приведенным ниже фильтром пути будет выполняться только при событиях `push` с по крайней мере одним файлом за пределами каталога `docs` в корне репозитория.\n\n```yaml\non:\n  push:\n    paths-ignore:\n      - 'docs/**'\n```\n\n#### Пример. Включение и исключение путей\n\nНельзя использовать `paths` и `paths-ignore` для фильтрации одного и того же события в одном рабочем процессе. Если вы хотите включить и исключить шаблоны путей для одного события, используйте `paths` префикс фильтра с `!` символом, чтобы указать, какие пути следует исключить.\n\nЕсли вы определяете путь с символом `!`, необходимо также определить по крайней мере один путь без символа `!`. Если вы хотите только исключить пути, используйте вместо этого `paths-ignore`.\n\nПорядок определения `paths` шаблонов имеет значение:\n\n* Соответствующий отрицательный шаблон (с префиксом `!`) после положительного совпадения исключает путь.\n* Соответствующий положительный шаблон после отрицательного совпадения снова включает путь.\n\nЭтот пример запускается каждый раз, когда событие `push` включает файл в каталоге `sub-project` или его подкаталогах, но не в каталоге `sub-project/docs`. Например, принудительная отправка с изменением `sub-project/index.js` или `sub-project/src/index.js` запустит выполнение рабочего процесса, но принудительная отправка, изменяющая только `sub-project/docs/readme.md`, не запустит его.\n\n```yaml\non:\n  push:\n    paths:\n      - 'sub-project/**'\n      - '!sub-project/docs/**'\n```\n\n#### Сравнение различий в GIT\n\nФильтр определяет, должен ли запускаться рабочий процесс, оценивая измененные файлы и проверяя их по списку `paths-ignore` или `paths`. Если измененных файлов нет, рабочий процесс не запускается.\n\nGitHub Создает список измененных файлов с помощью двухточийных диффов для отправки и трехточийных диффов для запросов на вытягивание:\n\n* **Запросы на вытягивание**. Различия с тремя точками — это сравнение последней версией тематической ветки с фиксацией, в которой тематическая ветка была в последний раз синхронизирована с основной ветвью.\n* **Отправки в существующие ветви**. Различие с двумя точками — это сравнение головных и базовых значений SHA непосредственно друг с другом.\n* **Отправки в новые ветви**. Различие с двумя точками в сравнении с родителем предка самой глубокой отправленной фиксации.\n\nВ некоторых ситуациях применяются ограничения, GitHub Actions которые изменяют способ выполнения фильтруемых рабочих процессов:\n\n* Если push-отправка содержит более 1000 фиксаций, рабочий процесс **всегда** будет выполняться.\n* При создании времени ожидания диффа рабочий процесс **всегда** будет выполняться.\n* Если созданный дифф содержит более 3000 файлов, а файлы, соответствующие фильтрам рабочих процессов, не находятся в первом 3000, возвращаемом фильтром, рабочий процесс **не** будет выполняться.\n\nЕсли вы наблюдаете это поведение, может потребоваться сделать фильтры более конкретными или изменить способ работы с push-отправками и запросами на вытягивание для создания более простых диффов.\n\nДополнительные сведения см. в разделе [Филиалы](/ru/pull-requests/reference/branches).\n\n### Использование фильтров для назначения определенных ветвей для событий выполнения рабочего процесса\n\nПри использовании события `workflow_run` можно указать, в каких ветвях должен выполняться запускающий рабочий процесс, чтобы активировать ваш рабочий процесс.\n\nВ фильтрах `branches` и `branches-ignore` можно использовать стандартные маски с такими символами, как `*`, `**`, `+`, `?`, `!` и другие, для сопоставления нескольких имен ветвей. Если имя содержит любой из этих символов, и требуется буквальное совпадение, необходимо *экранировать* каждый из этих специальных символов с помощью `\\`. Дополнительные сведения о шаблонах глобов см. в [разделе AUTOTITLE](/ru/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet).\n\nНапример, рабочий процесс со следующим триггером будет выполняться, только если рабочий процесс с именем `Build` выполняется в ветви, имя которой начинается с `releases/`.\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches:\n      - 'releases/**'\n```\n\nРабочий процесс со следующим триггером будет выполняться, только если рабочий процесс с именем `Build` выполняется в ветви с именем отличным от `canary`.\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches-ignore:\n      - \"canary\"\n```\n\nДля одного и того же события в рабочем процессе нельзя использовать фильтры `branches` и `branches-ignore` одновременно. Если вам нужно с помощью шаблонов одновременно включить и исключить имена ветвей для одного события, используйте фильтр `branches` с символом `!`, чтобы указать, какие ветви следует исключить.\n\nПорядок определения шаблонов имеет значение.\n\n* Если после включающего шаблона идет исключающий (с префиксом `!`) и найдена ветвь, соответствующая им обоим, такая ветвь исключается.\n* Если после исключающего шаблона идет включающий, ветвь, соответствующая им обоим, снова включается.\n\nНапример, рабочий процесс со следующим триггером будет выполняться, если рабочий процесс с именем `Build` выполняется в ветви с именем `releases/10` или `releases/beta/mona`, но не в ветви `releases/10-alpha`, `releases/beta/3-alpha` или `main`. <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n## Определение входных данных для рабочих процессов, активированных вручную\n\nПри использовании события `workflow_dispatch` можно дополнительно указать входные данные, передаваемые рабочему процессу.\n\nЭтот триггер получает события только в том случае, если файл рабочего процесса находится на ветвь по умолчанию.\nАктивированный рабочий процесс получает входные данные в контексте `inputs`. Дополнительные сведения см. в разделе [\"Контексты](/ru/actions/reference/workflows-and-actions/contexts#inputs-context)\".\n\n> \\[!NOTE]\n>\n> * Рабочий процесс также получит входные данные в контексте `github.event.inputs` . Информация в контексте `inputs` и в контексте `github.event.inputs` идентична, за исключением того, что контекст `inputs` сохраняет логические значения в исходном формате логических значений, не преобразовывая их в строки. Тип `choice` разрешается в строку и является одним вариантом выбора.\n> * Максимальное количество свойств верхнего уровня для `inputs` — 25 .\n> * Максимальная полезная нагрузка составляет `inputs` 65 535 символов.\n\n```yaml\non:\n  workflow_dispatch:\n    inputs:\n      logLevel:\n        description: 'Log level'\n        required: true\n        default: 'warning'\n        type: choice\n        options:\n          - info\n          - warning\n          - debug\n      print_tags:\n        description: 'True to print to STDOUT'\n        required: true\n        type: boolean\n      tags:\n        description: 'Test scenario tags'\n        required: true\n        type: string\n      environment:\n        description: 'Environment to run tests against'\n        type: environment\n        required: true\n\njobs:\n  print-tag:\n    runs-on: ubuntu-latest\n    if: ${{ inputs.print_tags }} \n    steps:\n      - name: Print the input tag to STDOUT\n        run: echo  The tags are ${{ inputs.tags }} \n```\n\n## Определение входных, выходных данных и секретов для повторно используемых рабочих процессов\n\nВы можете определить входные данные и секреты, которые рабочий процесс, доступный для повторного использования, должен получать от вызывающего рабочего процесса. Вы также можете указать выходные данные, которые повторно используемый рабочий процесс сделает доступным для вызывающего рабочего процесса. Дополнительные сведения см. в разделе [Повторное использование рабочих процессов](/ru/actions/how-tos/reuse-automations/reuse-workflows).\n\n## Использование сведений о событии\n\nСведения о событии, которое активировало рабочий процесс, доступны в контексте `github.event`. Свойства в контексте `github.event` зависят от типа события, которое активировало рабочий процесс. Например, рабочий процесс, запускаемый при присвоении метки проблеме, будет содержать сведения о проблеме и метке.\n\n### Просмотр всех свойств события\n\nОбратитесь к документации по событиям веб-перехватчиков, чтобы ознакомиться с общими свойствами и примерами полезных данных. Дополнительные сведения см. в разделе [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads).\n\nВы также можете распечатать весь контекст `github.event`, чтобы узнать, какие свойства доступны для события, которое активировало рабочий процесс:\n\n```yaml\njobs:\n  print_context:\n    runs-on: ubuntu-latest\n    steps:\n      - env:\n          EVENT_CONTEXT: ${{ toJSON(github.event) }}\n        run: |\n          echo $EVENT_CONTEXT\n```\n\n### Доступ к свойствам события и их использование\n\nВы можете использовать контекст `github.event` в своем рабочем процессе. Например, следующий рабочий процесс выполняется при открытии запроса на вытягивание, который изменяет `package*.json`, `.github/CODEOWNERS` или `.github/workflows/**`. Если автор pull request (`github.event.pull_request.user.login`) не `octobot` является или `dependabot[bot]`, то рабочий процесс использует GitHub CLI , чтобы помечать и комментировать pull request (`github.event.pull_request.number`).\n\n```yaml\non:\n  pull_request:\n    types:\n      - opened\n    paths:\n      - '.github/workflows/**'\n      - '.github/CODEOWNERS'\n      - 'package*.json'\n\njobs:\n  triage:\n    if: >-\n      github.event.pull_request.user.login != 'octobot' &&\n      github.event.pull_request.user.login != 'dependabot[bot]'\n    runs-on: ubuntu-latest\n    steps:\n      - name: \"Comment about changes we can't accept\"\n        env:\n          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n          PR: ${{ github.event.pull_request.html_url }}\n        run: |\n          gh pr edit $PR --add-label 'invalid'\n          gh pr comment $PR --body 'It looks like you edited `package*.json`, `.github/CODEOWNERS`, or `.github/workflows/**`. We do not allow contributions to these files. Please review our [contributing guidelines](https://github.com/octo-org/octo-repo/blob/main/CONTRIBUTING.md) for what contributions are accepted.'\n```\n\nДополнительные сведения о контекстах см. в разделе [Справочник по контекстам](/ru/actions/reference/workflows-and-actions/contexts). Дополнительные сведения о полезных данных событий см. в разделе [События и полезные данные веб-перехватчика](/ru/webhooks/webhook-events-and-payloads).\n\n## Дальнейшее управление запуском рабочего процесса\n\nЕсли требуется более детализированный контроль, чем события, типы действий событий или фильтры событий, можно использовать условные выражения и среды для управления выполнением отдельных заданий или шагов в рабочем процессе.\n\n### Использование условных выражений\n\nУсловные выражения можно использовать для дальнейшего управления выполнением заданий или шагов в рабочем процессе.\n\n#### Пример использования значения в полезных данных события\n\nНапример, если требуется, чтобы рабочий процесс выполнялся при добавлении определенной метки в проблему, можно активировать тип действия события `issues labeled` и использовать условное выражение для проверки того, какая метка активировала рабочий процесс. Следующий рабочий процесс будет выполняться при добавлении метки в проблему в репозитории рабочего процесса, но задание `run_if_label_matches` будет выполняться только в том случае, если метка называется `bug`.\n\n```yaml\non:\n  issues:\n    types:\n      - labeled\n\njobs:\n  run_if_label_matches:\n    if: github.event.label.name == 'bug'\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo 'The label was bug'\n```\n\n#### Пример использования типа события\n\nНапример, если вы хотите выполнять различные задания или шаги в зависимости от того, какое событие активировало рабочий процесс, можно использовать условное выражение, чтобы проверить, существует ли определенный тип события в контексте события. Следующий рабочий процесс будет выполняться при закрытии проблемы или запроса на вытягивание. Если рабочий процесс были выполнен по причине закрытия проблемы, контекст `github.event` будет содержать значение для `issue`, но не для `pull_request`. Поэтому шаг `if_issue` будет выполняться, а шаг `if_pr` не будет выполняться. Если рабочий процесс были выполнен по причине закрытия запроса на вытягивание,шаг `if_pr` будет выполняться, а шаг `if_issue` — нет.\n\n```yaml\non:\n  issues:\n    types:\n      - closed\n  pull_request:\n    types:\n      - closed\n\njobs:\n  state_event_type:\n    runs-on: ubuntu-latest\n    steps:\n    - name: if_issue\n      if: github.event.issue\n      run: |\n        echo An issue was closed\n    - name: if_pr\n      if: github.event.pull_request\n      run: |\n        echo A pull request was closed\n```\n\nДополнительные сведения о том, какие сведения доступны в контексте события, см. в разделе [\"Использование сведений](#using-event-information) о событии\". Дополнительные сведения об использовании условных условий см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/actions/reference/workflows-and-actions/expressions).\n\n### Использование сред для активации заданий рабочих процессов вручную\n\nЕсли вы хотите вручную активировать определенное задание в рабочем процессе, можно использовать среду, требующую утверждения от определенной команды или пользователя. Сначала настройте среду с необходимыми рецензентами. Дополнительные сведения см. в разделе [Управление средами для развертывания](/ru/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments). Затем укажите имя среды в задании в рабочем процессе с помощью ключа `environment:`. Любое задание, ссылающееся на среду, не будет выполняться, пока хотя бы один рецензент не утвердит задание.\n\nНапример, следующий рабочий процесс будет выполняться всякий раз, когда выполняется отправка в главную ветвь. Задание `build` будет выполняться всегда. Задание `publish` будет выполняться только после успешного завершения задания `build` (ввиду `needs: [build]`) и после соблюдения требований всех правил (включая обязательных рецензентов) для среды, называемой `production` (ввиду `environment: production`).\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - name: build\n        run: |\n          echo 'building'\n\n  publish:\n    needs: [build]\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: publish\n        run: |\n          echo 'publishing'\n```\n\n> \\[!NOTE]\n> Окружения, секреты окружающей среды и правила защиты при развертывании доступны в публичных хранилищах для всех текущих GitHub планов. Они недоступны в устаревших планах, таких как Бронза, Silver или Gold. Для доступа к средам, секретам окружения и веткам развертывания в частных или внутренних репозиториях необходимо использовать GitHub Pro, GitHub Team, или GitHub Enterprise.\n> Если вы находитесь на GitHub Free, GitHub Proили GitHub Team планируете, другие правила защиты развертывания, такие как таймер ожидания или обязательные рецензенты, доступны только для публичных репозиториев.\n\n## Доступные события\n\nПолный список доступных событий см. в разделе [События, инициирующие рабочие процессы](/ru/actions/reference/workflows-and-actions/events-that-trigger-workflows)."}