Работали ли вы с Jenkins и настраивали ли пайплайны самостоятельно или через UI

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

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

Как отвечать

Скажите честно, что делали сами. Сильный вариант: пайплайн живёт в репозитории как код, проходит ревью вместе с тестами, а настройка через интерфейс остаётся для разовых задач, потому что её нельзя ни повторить, ни посмотреть в истории изменений.

pipeline {
  agent { label 'linux' }
  stages {
    stage('tests') {
      steps { sh 'pytest -n 4 --junitxml=report.xml' }
    }
  }
  post { always { junit 'report.xml' } }
}

Дальше перечислите то, что реально приходится настраивать: параметры сборки (стенд, набор тестов, браузер), запуск по коммиту и по расписанию, параллельные стадии, публикацию отчёта и артефактов (скриншоты, логи, видео), timeout и retry вокруг нестабильных шагов, секреты через хранилище учётных данных, агента в контейнере ради воспроизводимого окружения.

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

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

Собирают джобу в интерфейсе и не могут её повторить. Конфигурация существует в одном экземпляре, кто и что менял, неизвестно, а после переезда сервера всё настраивается заново по памяти.

Второе: не разделяют падение теста и падение инфраструктуры. Когда стенд не поднялся, а сборка помечена как провал тестов, статистика перестаёт что-либо значить, и команда привыкает к красному.

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