Какие триггеры сборки существуют в Jenkins?
Триггер сборки (build trigger) — это механизм, определяющий, при каком событии Jenkins автоматически запускает выполнение пайплайна или джобы.
Представьте, что триггер — это дверной звонок. Webhook — это когда курьер (Git-сервер) сам нажимает кнопку звонка при доставке. SCM Polling — это когда вы каждые пять минут выглядываете в окно, не пришёл ли курьер. Cron — это когда вы выходите проверять почтовый ящик каждый день в одно и то же время, независимо от того, ждёте ли вы посылку.
1. Webhook (рекомендуемый способ)
Git-сервер (GitHub, GitLab, Bitbucket) отправляет HTTP-запрос (webhook) в Jenkins при наступлении события (push, merge, создание Pull Request). Это наиболее эффективный подход:
- Мгновенная реакция — сборка стартует сразу после push.
- Нет лишней нагрузки — Jenkins не тратит ресурсы на периодический опрос.
- Требует сетевой доступности — Git-сервер должен иметь возможность отправить HTTP-запрос в Jenkins.
Пример
// Для GitHub:
triggers {
githubPush()
}
// Для GitLab:
triggers {
gitlab(triggerOnPush: true, triggerOnMergeRequest: true)
}
2. SCM Polling (опрос системы контроля версий)
Jenkins периодически проверяет репозиторий на наличие новых коммитов. Если обнаружены изменения — запускается сборка.
- Используется, когда webhook невозможен (закрытый контур, сетевые ограничения, firewall).
- Создаёт дополнительную нагрузку на Jenkins и Git-сервер.
Пример
triggers {
pollSCM('H/5 * * * *') // Проверка каждые 5 минут
}
3. Cron (по расписанию)
Сборка запускается строго по расписанию, независимо от наличия изменений в коде. Подходит для:
- Ночных (nightly) сборок с полным набором тестов.
- Регулярных проверок безопасности зависимостей (OWASP).
- Периодической генерации отчётов.
Пример
triggers {
cron('H 2 * * 1-5') // В ~2 часа ночи по будням
}
Синтаксис: MINUTE HOUR DOM MONTH DOW (как в Unix cron). Символ H — хеш-функция от имени джобы, распределяющая нагрузку, чтобы не все джобы стартовали одновременно.
4. Upstream (по завершению другой сборки)
Сборка запускается после успешного завершения другого проекта в Jenkins. Полезно для цепочек зависимостей — например, сначала собирается общая библиотека, затем зависимые сервисы.
Пример
triggers {
upstream(upstreamProjects: 'core-library/main', threshold: hudson.model.Result.SUCCESS)
}
5. Ручной запуск
- Через веб-интерфейс Jenkins (кнопка «Build Now» / «Build with Parameters»).
- Через REST API:
Пример
curl -X POST https://jenkins.company.com/job/my-job/build
- Через CLI:
java -jar jenkins-cli.jar -s https://jenkins.company.com build my-job.
Сравнение триггеров
| Триггер | Реакция | Нагрузка | Когда использовать |
|---|---|---|---|
| Webhook | Мгновенная | Минимальная | Основной способ для feature-веток |
| SCM Polling | С задержкой | Средняя | Закрытый контур без webhook |
| Cron | По расписанию | Минимальная | Nightly-сборки, security-сканы |
| Upstream | После другой сборки | Нет | Цепочки зависимых проектов |
| Ручной | По требованию | Нет | Деплой на production |
Вывод
В банковской практике чаще всего используется комбинация: webhook для веток разработки (быстрая обратная связь), cron для ночных проверок безопасности и ручной запуск с параметрами для деплоя на production.
На собеседовании: обычно спрашивают, чем webhook отличается от polling и почему webhook предпочтительнее. Ключевой ответ — webhook реактивен (push-модель), polling активен (pull-модель). Webhook даёт мгновенную реакцию без лишней нагрузки, но требует сетевой доступности Jenkins для Git-сервера.