Jenkins запускает selenium тесты, каждые 10 мин. Хочу сделать так:
Если билд провалился, то сразу его запустить один раз автоматически.
Установил Periodic Reincarnation Plugin, настроил, но когда валится билд, то следующий запускается только через 5 мин. Я уже все перетыкал, не знаю куда копать…Может подскажете?
Сам вопрос уже довольно костыльный и я бы копал немного глубже чем просто перезапуск каждую минуту, но раз так пошло, то поставь https://wiki.jenkins-ci.org/display/JENKINS/Run+Condition+Plugin , который бы смотрел на результат билда и запускал эту же джобу, если она упала.
Хотя из твоей постановки уже могу предвидеть кучу проблем и велосипедов. Представь что билд валится из-за того что что-то реально сломалось на сайте (изменилась верстка), в таком случае твой тест будет запускаться снова и снова? А потом через 10 минут он запустится еще раз, упадет и у тебя будет второй поток запускаться снова и снова, а потом третий и так до бесконечности.
Наиболее просто способ: написать external скрипт и добавить его как отдельную “B” сборку, которая должна запускаться после окончания свалившейся “А” сборки. В скрипте должен быть реализован REST API запрос на запуск “А” сборки, если выполняются два условия: статус последней сборки “A” - failed и другой статус: кол-во запусков рекурсивно из этого скрипта == 0. После rest api запроса кол-во запусков с 0 изменить на 1 и передать в переменную окружения (через python например не получится, но получится через bash shell, чтобы она была не process-binded, а глобально доступная после завершения процесса), либо просто создать рядом текстовый файл и написать в него счетчик(1\0) - бинарной логики для единократного перезапуска хватит. В случае если должно запускаться нужное кол-во раз - инкрементируйте этот флаг до тех пор (а значит и запускайте задачу), пока она не сравняется с кол-вом запусков, указанных вами в скрипте.
Если есть возможность - лучше перезапускать конкретно упавшие тесты чем билд целиком на Jenkins
Вот пример для Maven surefire plugin -
https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html
Позвольте заметить:
Если это системные или GUI тесты - совсем не факт, что эти тесты являются между собой независимыми. Чаще всего тестовые фреймворки типа JUnit или Pytest являют собой удобное средство для систематизации теста, но воссоздание контекста в рамках desktop application testing - вещь дорогая по времени и правдивости самого контекста, чтобы реализовывать ее через setUp\tearDown методы.
Конкретно упавшие тесты и их пере запуск - вещь сугубо юнит-тест\api тест ориентированная.
Я не совсем уловил замечание. Там ведь Selenium используется - значит тесты для сайта гоняются. А раз так - тесты (должны во всяком случае) стартовать с чистой сессией, куками, и local\session storage - контекст всегда будет новый.
Не согласен. UI тесты гораздо более нестабильны чем юнит\api тесты - перезапуск упавшего теста несколько раз очень даже имеет смысл чтобы исключить кучу ложных срабатываний типа страничка затупила и долго открывалась, браузер залагал, кнопка не успела прогрузится и т.д.
Ах да, Селениум. В том и дело, что для UI тестов в вебе “несколько раз очень даже имеет смысл чтобы исключить” легко реализуется повторяемым и аналогичным свежим контекстом, что очень и очень хорошо вписывается в рамки современного (читай, RESTful) UI веб-приложения.
Для тестирования десктоп приложений через UI все несколько иначе: для валидационных билд тестов, регрессионных, системных, интеграционных и т.д.
Хмм…А можно ли это реализовать в Дженкинсе?
Есть проект на C++. Собирается долго, минут 30. Это отдельный проект в Дженкинсе. После его сборки, запускается другой проект, в котором запускаются тесты на уже собранное приложение. Может так случиться, что тест провалится, можно ли сделать перезапуск именно провалившегося теста через Дженкинс, не перезапуская все тесты снова?
Насчет С++ не уверен, ведь это фича уже не дженкинса а раннера.
Значит у вас плохие тесты.
Или что бы пропустить мажорный “плавающий” баг - когда “страничка” открывается “бесконечно” долго, а кнопка так и не прогрузится и пользователь ее никогда не увидит.
Смысл в ре-ране фейлов - это не “долбление” до “зеленого бублика”, а увидели фейлы - пофиксили AUT/тесты- и перезапустили.
А что вы используете для рана с++ тестов? ctest/cmake? Я в одном проекте просто парсил лог ctest-a (например этим - Log Parser) и запускал сфейленные через:
ctest -R '^TestOne&|^TestTwo&|^TestThree&'
Тесты написаны на Python. Запускаются с помощью PyTest. Тестируется GUI интерфейс и api приложения
Тогда это вообще просто, есть куча уже готовых плагинов, которые реранят упавшие тесты:
https://pytest.org/latest/xdist.html
и тд
Но все же мне не ясно, как их запускать через Дженкинс?
Создавать отдельный проект?
Или как?
Если нужны зелёные тесты, то это решение получше будет: GitHub - auchenberg/volkswagen: Volkswagen detects when your tests are being run in a CI server, and makes them pass.
testomat.io управление авто тестами