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

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

Настраивали ли вы запуск автотестов сами или только смотрели на цвет сборки. Следом обычно спрашивают, как тесты гоняются на пул-реквестах и где смотреть результат упавшего прогона.

Как отвечать

Начните с того, что пайплайн сейчас описывают кодом в Jenkinsfile рядом с тестами, а Freestyle-джобы из интерфейса остаются для простых случаев. Дальше триггеры:

• вебхук: GitHub или GitLab на каждый пуш дёргает Jenkins через свой плагин. Самый быстрый вариант;
• Multibranch Pipeline: Jenkins сам находит ветки и пул-реквесты с Jenkinsfile и собирает каждый отдельно. Так тесты проходят до слияния;
• pollSCM: опрос репозитория, например pollSCM('H/15 * * * *'). Запасной путь, если вебхук не проходит по сети;
• cron: ночной регресс, например cron('H 2 * * 1-5'). Символ H разносит старт джоб по времени, чтобы они не стартовали в одну минуту;
• upstream: запуск после успешной сборки другой джобы, например e2e после деплоя на стенд;
• ручной запуск с параметрами: блок parameters с выбором окружения, браузера, набора тегов.

Из настроек стоит назвать:

• агенты: agent { label 'linux' } или Docker-агент с нужным браузером и JDK, чтобы окружение воспроизводилось;
• параллельность: parallel для стадий или шардинг тестов по агентам;
• таймауты: options { timeout(...) }, чтобы зависший браузер не держал агент часами;
• отчёты: шаг junit в post { always { ... } }, чтобы отчёт публиковался и при падении, плюс Allure и archiveArtifacts для скриншотов и логов.

Если вы только пользовались готовым пайплайном, скажите это и опишите, что умеете: читать Jenkinsfile, перезапускать с параметрами, разбирать отчёт.

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

Публикуют отчёт только при успешном прогоне. Тесты упали, а результатов в Jenkins нет.

Ставят pollSCM раз в минуту на десятки репозиториев и нагружают Git-сервер, хотя есть вебхуки.

Лечат нестабильные тесты глобальным retry(3). Флаки перестают быть видны, но никуда не деваются.