Привет всем!
С дженкинсом, я только недавно начал работать, и пока не очень разбираюсь во всех тонкостях, возникла такая задача:
Необходимо параметризировать количество запускаемых сборок по одному джобу в Jenkins.
Количество параллельно запускаемых сборок должно выбираться перед принудительным запуском сборки, по дефолту параметр должен быть равен 1.
Установил в настройках сборки чек-бокс “Это - параметризованная сборка” - с этим все ок, перед запуском сборки запрашивается значение указанных переменных;
Установил чек-бокс “Разрешить параллельный запуск задачи” - с этим тоже все ок, сборки запускаются параллельно;
Для запуска n-числа сборок, пробовал добавить в настройках сборки шаг “trigger/call builds on other projects” c параметром invoke i=0…N builds, где указал значения переменных (from, to, step)…
но, когда принудительно запускаю сборку, указываю параметры, например from=1 и to=2, то запускаются не две одновременных сборки, а больше, штук 8-10, складывается такое впечатление, что они запускаются рекурсивно.
Я пока не могу до конца понять логику работы этого шага.
Пробовал искать в гугле документацию по шагу “trigger/call builds on other projects”, но она очень скудная.
Может у кого-то есть опыт решения подобной задачи, поделитесь пожалуйста.
Главный вопрос - зачем вам это нужно? Какие процессы вы собираетесь параллелить? На основании чего решили, что N параллельных билдов - это хорошая идея? Как правило, CI используют для решения сложных задач, которые могут потреблять достаточно много ресурсов. И если у вас не супер-компьютер, то такая затея может обернуться падением сервера, проблемами с производительностью, утечками памяти, недостатком свободного места и т.п.
В сборке проверяется прохождение заявки по некому процессу бизнес-процессу (авто-тесты реализованы в SoapUI). Предполагается, что ручные тестировщики будут использовать созданные заявки во время теста в jenkins для дальнейшего тестирования, то есть ручному тестировщику необходимо для тестирования 3 заявки, он принудительно запускает(по расписанию, по-умолчанию, будет запускаться только одна сборка) сборку с числом 3, запускается три параллельных сборки, таким образом он получает необходимые заявки и параллельно проверяется процесс прохождения заявки.
Насколько я правильно понял, заявки, создаваемые в параллели, должны быть разные, так? Как вы решаете данную проблему? Я веду к тому, что если стоит задача параллелизации тестов, а не сборок (а в вашем случае это именно тесты), то сам процесс распараллеливания необходимо осуществлять на уровне кода, а не CI, хотя бы потому, что CI вообще глубоко плевать на валидность данных, подлежащих масштабированию. С SoapUI не работал, но подозреваю, что проблем интеграции с TestNG или JUnit быть не должно. Собственно в таком случае, вы можете свести задачу распараллеливания на плечи тестового фреймворка, а сам параметр кол-ва потоков можно попробовать читать из джобы. Но опять-таки, проблема подсовывания разных данных разным потокам лежит на вас, а не на CI.
Тип заявок один и тот же, но данные немного разные, это обеспечивается рандомизацией, которая реализована в самих авто-тестах (с помощью Groovy скриптов).
Для запуска авто-тестов в jenkins я использую SoapUI приложение testrunner.bat, есть еще приложение loadtestrunner.bat (предназначенное для нагрузочного тестирования, можно в качестве параметра передавать количество требуемых потоков) что в принципе решает задачу, но если использовать его для запуска нет детального логирования в консоль jenkins(что упрощает поиск места, где возникла ошибка в случае фейла сборки).
testomat.io управление авто тестами