Как выполнять ту же работу несколько раз параллельно с Дженкинсом?

Question

Я тестирую Дженкинса, чтобы узнать, соответствует ли он нашей структуре сборки и тестирования. Я обнаружил, что Jenkins и его доступные плагины соответствуют большинству наших потребностей. За исключением того, что я не могу найти помощь в том, как выполнять один конкретный тип задачи.

Мы создаем приложение для встроенных устройств. У нас есть 100 тестов, которые нужно запускать на этих устройствах. Если мы проведем все тесты на одном устройстве после сборки, для получения результатов потребуется несколько часов. Однако, если мы проведем тесты на 100 параллельных устройств, мы получим результаты в гораздо более короткие сроки.

Все испытания будут иметь очень похожую начальную точку. Сценарий тестирования вызывается с IP-адресом устройства для запуска теста и имени пользователя/pw. Скрипт выполнит необходимый тест на устройстве и сообщит о прохождении/сбое для каждого тестового элемента.

Я думаю, что длинный/болезненный способ сделать это - написать 100 заданий в Дженкинсе, каждый из которых будет представлять собой отдельный тестовый скрипт напрямую (с приведенными выше параметрами) и запускать их параллельно с помощью доступных плагинов. Тем не менее, сохранить все эти рабочие места будет очень сложно в долгосрочной перспективе.

Таким образом, лучший способ сделать это - создать Job (назовем его child_tester), который может принимать такие параметры, как: имя сценария тестирования, IP-адрес устройства, имя пользователя/pw и т. Д. Затем используйте другой задание (назовем его mother_tester), чтобы вызывать работу child_tester 100 раз с разными IP-адресами и запускать их параллельно. Мне нужен какой-то способ накопления всех результатов теста каждого отдельного запуска заданий child_tester и сообщить о них обратно в mother_tester.

У меня вопрос, есть ли плагин или любой способ выполнить это в Дженкинсе? Я просмотрел информацию о плагинах «Build Flow», «Parallel Test Executor» и «Parameterized Trigger». Однако они, похоже, не соответствуют моим потребностям.

Благодарим за помощь.

Answer 1

Насколько я понимаю, вы заглянули в плагин Build Flow, но я не уверен, почему вы его уволили. Возможно, вы можете указать на дыры в моем предложении.

Предполагая, что у вас достаточно исполнителей в вашей системе для параллельной работы, я думаю, что Build Flow plugin и Build Flow Test Aggregator plugin могут делать то, что вы хотите.

• Плагин поддержки потоковой сборки running jobs in parallel. Я не вижу причин, по которым Build Flow не может планировать ваше «дочернее» задание параллельно с разными параметрами.

• Агрегатор тестирования потока сборки захватывает результаты тестов из запланированных сборок задания потока сборки, поэтому ваша «детская» работа должна будет опубликовать собственные результаты тестирования.

• Вам нужно будет настроить свое «дочернее» задание, чтобы оно выполнялось параллельно, путем проверки «Выполнять параллельные сборки при необходимости» в конфигурации задания.

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

---

Update: с простым определением сборки Flow:

parallel (
    { build("dbacher flow child", VALUE: 1) }, 
    { build("dbacher flow child", VALUE: 2) }, 
    { build("dbacher flow child", VALUE: 3) }, 
    { build("dbacher flow child", VALUE: 4) } 
) 

Я получаю результат:

parallel { 
    Schedule job dbacher flow child 
    Schedule job dbacher flow child 
    Schedule job dbacher flow child 
    Schedule job dbacher flow child 
    Build dbacher flow child #5 started 
    Build dbacher flow child #6 started 
    Build dbacher flow child #7 started 
    Build dbacher flow child #8 started 
    dbacher flow child #6 completed 
    dbacher flow child #7 completed 
    dbacher flow child #5 completed 
    dbacher flow child #8 completed 
} 

Работа История показывает, что все четыре задания по расписанию в течение нескольких секунд друг от друга. Но шаг построения задания содержит искусственную задержку (спящий режим), которая не позволяет быстро завершить выполнение одной отдельной сборки.

---

Update 2: Вот пример создания списка параллельных задач динамически из другой структуры данных:

// create a closure for the deploy job for each server 
def paramValues = (1..4) 
def testJobs = [] 
for (param in paramValues) { 
    def jobParams = [VALUE: param] 
    def testJob = { 
    // call build 
    build(jobParams, "dbacher flow child") 
    } 
    println jobParams 
    testJobs.add(testJob) 
} 

parallel(testJobs) 

В списке передается параллельно приводится список закрытий, которые требуют сборки с уникальными параметрами. Я должен был обязательно определить параметры работы за пределами функции закрытия, чтобы гарантировать, что задания будут запланированы отдельно.

Я подкрепил синтаксис от другого answer и this thread в списке рассылки Jenkins.

Answer 2

Пожалуйста, убедитесь, что количество исполнителей в настройках Управление настройками Jenkins -> Manage Nodes больше, чем количество отдельных заданий в проекте MultiJob. По умолчанию, я думаю, это 2. Следовательно, нам нужно увеличить его.