Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Авторестарт неудачного билда в Jenkins каждую минуту

jenkins
Теги: #<Tag:0x00007f7b626a56f0>

(Пётр Алексеев) #1

Jenkins запускает selenium тесты, каждые 10 мин. Хочу сделать так:
Если билд провалился, то сразу его запустить один раз автоматически.

Установил Periodic Reincarnation Plugin, настроил, но когда валится билд, то следующий запускается только через 5 мин. Я уже все перетыкал, не знаю куда копать…Может подскажете?


(Евгений Бухгаммер) #2

пробовали Naginator Plugin? https://wiki.jenkins-ci.org/display/JENKINS/Naginator+Plugin


(Stan) #3

Сам вопрос уже довольно костыльный и я бы копал немного глубже чем просто перезапуск каждую минуту, но раз так пошло, то поставь https://wiki.jenkins-ci.org/display/JENKINS/Run+Condition+Plugin , который бы смотрел на результат билда и запускал эту же джобу, если она упала.

Хотя из твоей постановки уже могу предвидеть кучу проблем и велосипедов. Представь что билд валится из-за того что что-то реально сломалось на сайте (изменилась верстка), в таком случае твой тест будет запускаться снова и снова? А потом через 10 минут он запустится еще раз, упадет и у тебя будет второй поток запускаться снова и снова, а потом третий и так до бесконечности.


(Евгений Бухгаммер) #4

Наиболее просто способ: написать external скрипт и добавить его как отдельную “B” сборку, которая должна запускаться после окончания свалившейся “А” сборки. В скрипте должен быть реализован REST API запрос на запуск “А” сборки, если выполняются два условия: статус последней сборки “A” - failed и другой статус: кол-во запусков рекурсивно из этого скрипта == 0. После rest api запроса кол-во запусков с 0 изменить на 1 и передать в переменную окружения (через python например не получится, но получится через bash shell, чтобы она была не process-binded, а глобально доступная после завершения процесса), либо просто создать рядом текстовый файл и написать в него счетчик(1\0) - бинарной логики для единократного перезапуска хватит. В случае если должно запускаться нужное кол-во раз - инкрементируйте этот флаг до тех пор (а значит и запускайте задачу), пока она не сравняется с кол-вом запусков, указанных вами в скрипте.


(Oleksandr Khotemskyi) #5

Если есть возможность - лучше перезапускать конкретно упавшие тесты чем билд целиком на Jenkins
Вот пример для Maven surefire plugin -
https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html


(Евгений Бухгаммер) #6

Позвольте заметить:

Если это системные или GUI тесты - совсем не факт, что эти тесты являются между собой независимыми. Чаще всего тестовые фреймворки типа JUnit или Pytest являют собой удобное средство для систематизации теста, но воссоздание контекста в рамках desktop application testing - вещь дорогая по времени и правдивости самого контекста, чтобы реализовывать ее через setUp\tearDown методы.

Конкретно упавшие тесты и их пере запуск - вещь сугубо юнит-тест\api тест ориентированная.


(Oleksandr Khotemskyi) #7

Я не совсем уловил замечание. Там ведь Selenium используется - значит тесты для сайта гоняются. А раз так - тесты (должны во всяком случае) стартовать с чистой сессией, куками, и local\session storage - контекст всегда будет новый.

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


(Евгений Бухгаммер) #8

Ах да, Селениум. В том и дело, что для UI тестов в вебе “несколько раз очень даже имеет смысл чтобы исключить” легко реализуется повторяемым и аналогичным свежим контекстом, что очень и очень хорошо вписывается в рамки современного (читай, RESTful) UI веб-приложения.

Для тестирования десктоп приложений через UI все несколько иначе: для валидационных билд тестов, регрессионных, системных, интеграционных и т.д.


(Пётр Алексеев) #9

Хмм…А можно ли это реализовать в Дженкинсе?
Есть проект на C++. Собирается долго, минут 30. Это отдельный проект в Дженкинсе. После его сборки, запускается другой проект, в котором запускаются тесты на уже собранное приложение. Может так случиться, что тест провалится, можно ли сделать перезапуск именно провалившегося теста через Дженкинс, не перезапуская все тесты снова?


(Oleksandr Khotemskyi) #10

Насчет С++ не уверен, ведь это фича уже не дженкинса а раннера.


(vmaximv) #11

Значит у вас плохие тесты.

Или что бы пропустить мажорный “плавающий” баг - когда “страничка” открывается “бесконечно” долго, а кнопка так и не прогрузится и пользователь ее никогда не увидит.

Смысл в ре-ране фейлов - это не “долбление” до “зеленого бублика”, а увидели фейлы - пофиксили AUT/тесты- и перезапустили.


(Stan) #12

А что вы используете для рана с++ тестов? ctest/cmake? Я в одном проекте просто парсил лог ctest-a (например этим - https://wiki.jenkins-ci.org/display/JENKINS/Log+Parser+Plugin) и запускал сфейленные через:
ctest -R '^TestOne&|^TestTwo&|^TestThree&'


(Пётр Алексеев) #13

Тесты написаны на Python. Запускаются с помощью PyTest. Тестируется GUI интерфейс и api приложения


(Stan) #14

Тогда это вообще просто, есть куча уже готовых плагинов, которые реранят упавшие тесты:



https://pytest.org/latest/xdist.html

и тд


(Пётр Алексеев) #15

Но все же мне не ясно, как их запускать через Дженкинс?
Создавать отдельный проект?
Или как?


(Igor) #16

Если нужны зелёные тесты, то это решение получше будет: https://github.com/auchenberg/volkswagen