Какие триггеры существуют для запуска пайплайна

Что проверяют

Понимаете ли вы, какие проверки запускать на каком событии, а не только знаете названия триггеров. Следом обычно спрашивают, как вы разделили бы тесты между проверкой merge request и ночным прогоном.

Как отвечать

Основные триггеры одинаковы во всех CI-системах, отличается синтаксис:

• push в ветку: самый частый. В GitLab CI источник виден в $CI_PIPELINE_SOURCE со значением push, в GitHub Actions это on: push с фильтром по веткам;
• merge request или pull request: прогон до слияния, merge_request_event в GitLab и pull_request в GitHub. Здесь нужны быстрые проверки: линтер, юнит-тесты, смоук API, чтобы результат приходил за минуты;
• расписание: Pipeline schedules в GitLab, schedule с cron-выражением в UTC в GitHub, блок triggers { cron(...) } в Jenkins. Сюда уходят полная регрессия и долгие e2e;
• ручной запуск: кнопка с параметрами, workflow_dispatch в GitHub или when: manual у джобы в GitLab. Удобно для прогона на выбранном стенде;
• тег или релиз: сборка и приёмочные тесты релизной версии;
• другой пайплайн или API: деплой на стейдж запускает автотесты в соседнем репозитории (trigger в GitLab, repository_dispatch или workflow_run в GitHub).

Для QA главное назвать, какой набор тестов висит на каком триггере: на MR быстрый и стабильный, после деплоя смоук окружения, ночью всё остальное с отчётом в Allure и уведомлением в чат.

Где спотыкаются

Запускают полную регрессию на каждый push. Пайплайн идёт час, разработчики перестают ждать результата, и тесты теряют смысл.

Настраивают ночной прогон и никому не присылают результат. Красный пайплайн, который никто не видит, ничем не лучше отсутствующего.

Забывают про фильтры по путям (rules: changes в GitLab, paths в GitHub): правка README гоняет весь e2e, а при слишком узком фильтре правка самих тестов не запускает ничего.