2014-12-08 2 views
2

У меня есть сервер Jenkins с полдюжины сборщиков. Каждая из этих сборников состоит из родительского задания, которое запускает где угодно между 4 и 6 меньшими заданиями, которые выполняются параллельно. Я использую плагин EC2, чтобы поддерживать количество активных подчиненных в соответствии с количеством построенных в очереди сборок. Или, другими словами, рабы все время идут и уходят. Каждое подчиненное устройство имеет 7 исполнителей (родительское задание + max (4, 6)).Как все работы сборки выполняются исключительно на одном узле?

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

Что я ищу - это способ, который не позволяет Дженкинсу использовать какие-либо неактивные исполнители узла, если все задания из предыдущей сборки все еще активны на нем.

Я провел день, экспериментируя с комбинацией плагина с параллельным строем дроссельной заслонки и плагина параметров NodeLabel. К сожалению, кажется, что есть ошибка, которая заставляет дроссельные сборки не вносить вклад в статистику загрузки подчиненного устройства. Это, в свою очередь, означает, что дроссельная сборка никогда не заставит Дженкинса развернуть дополнительных рабов. Очевидно, это совершенно неприемлемо.

ответ

1

Вы можете попытаться использовать «Эта сборка спараметрирован» и передать $ node_name в качестве параметра между сборками и затем использовать его в «Ограничить этот проект может быть запущен»

+0

, что это отличная идея , Я пробовал это раньше сегодня, но столкнулся с следующей проблемой: предположим, что есть 2 родительских задания в очереди, заставляя плагин EC2 разворачивать 2 новых подчиненных устройства. К сожалению, когда первый из этих рабов закончил вращаться, Дженкинс видит, что теперь есть 7 свободных исполнителей и сразу же переводит оба родительских задания на первого и второго исполнителей этого ведомого. Мне нужно избегать этого. – Reck

Смежные вопросы