Триггеры: on push, pull_request, schedule, workflow_dispatch
Учимся точно управлять тем, когда именно запускается workflow.
Ключ
onописывает события-триггеры; один workflow может реагировать сразу на несколько событий.
Самые частые триггеры
Большинство пайплайнов держатся на четырёх событиях:
| Триггер | Когда срабатывает |
push | При пуше коммитов в репозиторий. |
pull_request | При открытии/обновлении PR — основа проверок перед мержем. |
schedule | По расписанию (cron), например ночные прогоны. |
workflow_dispatch | Ручной запуск кнопкой из вкладки Actions. |
Несколько событий и фильтры
События можно комбинировать и сужать фильтрами по веткам и путям:
on:
push:
branches: [main, develop] # только эти ветки
paths:
- "src/**" # только если менялся код
- "!**.md" # но не markdown-файлы
pull_request:
branches: [main]
Фильтр paths экономит минуты: нет смысла гонять сборку, если правили только README. Восклицательный знак — отрицание (исключить путь).
Запуск по расписанию
Триггер schedule использует синтаксис cron в UTC. Пять полей: минута, час, день месяца, месяц, день недели.
on:
schedule:
- cron: "0 3 * * 1" # каждый понедельник в 03:00 UTC
Удобно для ночных полных тестов, проверки внешних зависимостей, чистки кэшей. Учтите: время — UTC, и точность старта не гарантируется до минуты при высокой нагрузке.
Ручной запуск с параметрами
workflow_dispatch добавляет кнопку «Run workflow» и может принимать параметры (inputs):
on:
workflow_dispatch:
inputs:
environment:
description: "Куда катим"
type: choice
options: [staging, production]
default: staging
Значение потом доступно как ${{ github.event.inputs.environment }}. Это типовой способ сделать управляемый «деплой по кнопке».
Итог
pushиpull_request— основа CI;schedule— для регулярных задач;workflow_dispatch— для ручного запуска.- Фильтры
branchesиpathsсужают запуски и экономят минуты. - cron работает в UTC; ручной триггер умеет принимать параметры (inputs).