Переконфигурируйте и перезагрузите подчиненное устройство Hudson/Jenkins как часть сборки

У меня есть настройка сервера Jenkins (Hudson), которая запускает тесты на разных подчиненных машинах. То, что я хочу сделать, это перенастроить ведомое устройство (используя удаленные API-интерфейсы), перезагрузить ведомое устройство, чтобы изменения вступили в силу, а затем продолжить оставшуюся часть теста. Есть два препятствия, с которыми я столкнулся до сих пор:

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

Возможно ли это? До сих пор я не нашел способ сделать это с помощью Jenkins или любого из его плагинов.

РЕДАКТИРОВАТЬ - Дальнейшее объяснение Мне действительно очень нравится рабская архитектура Дженкинса. В сочетании с уже доступными плагинами очень легко получить задания для подчиненного устройства, запустить и вернуть результаты. И возможность выбора любого подходящего подчиненного устройства позволяет автоматически распределять работу/тестирование.

В нашей ситуации мы используем виртуализированные (VMware) подчиненные машины. Достаточно просто написать script, который заставил бы Дженкинса использовать VMware PowerCLI для запуска виртуальной машины, когда ей нужно было работать на подчиненном устройстве, затем отправить на нее задание и вернуть результаты. Все хорошо.

EXCEPT. Часть настройки каждого теста состоит в том, чтобы немного изменить конфигурацию виртуальной машины. Отключить UAC, войти в систему как другой пользователь, установить другой драйвер и т.д. - для каждого из этих изменений требуется перезагрузка тестовой VM/slave до того, как изменения повлияют. Хотя я могу писать сценарии ведомого по требованию (Launch Method = Launch-slave через выполнение команды на ведущем устройстве), которые обрабатывают эту реконфигурацию и перезапускают ее, это должно быть сделано ДО РАБОТЫ. В этом случае возникает проблема - я не могу настроить ведомый, потому что тип изменений конфигурации зависит от выполняемого задания, которое происходит только после запуска ведомого.

Возможные решения
1) Используйте несколько подчиненных экземпляров на одной виртуальной машине. Это не сработает - некоторые из конфигураций являются взаимоисключающими, но Дженкинс этого не знает. Поэтому он попытался бы запустить одну подчиненную конфигурацию для одного задания, другого подчиненного для другого задания - и оба подчиненных устройства будут на одной виртуальной машине. Замки на заданиях не мешают этому, поскольку запуск подчиненного устройства не является частью задания.

2) (Оптимальный) Шаг сборки, позволяющий заданию знать, что это подчиненное соединение МОЖЕТ быть нарушено. На этапе сборки, возможно, придется включить некоторые параметры, чтобы Дженкинс знал, как подключить ведомое устройство (будет ли ведомое устройство автоматически подключаться, будет ли Jenkins запускать script, достаточно простого SSH). Шаг сборки будет обрабатывать отключение подчиненного устройства, игнорировать обычное отключение соединения, а затем выполнить повторное подключение. После возобновления работы ведомого устройства может произойти следующий шаг сборки. Возможно, тайм-аут для отказа от работы, если ведомое устройство не повторно подключается через определенное время.

** Текущее решение ** - менее оптимальное
Прямо сейчас я не могу использовать подчиненную функцию Дженкинса. Вместо этого я использую серию шагов сборки - запускается на главном компьютере, которые используют сценарии Windows и PowerShell для включения виртуальной машины, создания конфигураций и перезапуска. У VM есть сервер SSH, который работает на нем, и я использую это для загрузки тестовых файлов в тестовую виртуальную машину, а затем удаленное выполнение. Затем загрузите результаты обратно в Jenkins для обработки по заданию. Это решение является функциональным - но гораздо больше работы, чем обычный рабский подход Jenkins. Кроме того, сценарии нацелены на одну виртуальную машину; Я не могу легко использовать пул подчиненных.

Ответ 1

Очень легко. Вы создаете Мастер-задание, которое выполняется на Мастере, из главного задания, которое вы вызываете клиентским заданием, как шаг сборки (это новый шаг построения, и мне это нравится). Вам нужно проверить, что основное задание должно дождаться завершения задания клиента. Затем вы можете запустить script, чтобы перенастроить ваш клиент и запустить второй тест на клиенте.

Еще лучшая стратегия состоит в том, чтобы на ваших подчиненных машинах выполнялось два узла. Вам нужно настроить два узла в Jenkins. Я успешно использовал эту стратегию с помощью unix-slave. Причина в том, что мне нужны разные переменные среды, которые нужно настроить, и я не хотел толкать их в работу. Я использовал ssh-клиентов, поэтому я не знаю, возможно ли это с разными типами клиентов. Затем вы можете одновременно запускать оба теста или объединить задания или использовать вышеупомянутую стратегию.

Ответ 2

Не уверен, что это сработает для вас, но вы можете попробовать сделать агент Jenkins node программным способом сообщить мастеру node, что он отключен.

У меня была ситуация, когда мне нужно было выполнить задание Дженкинса, которое выполняет эти шаги (все время работы на главном node):

вернуть агент Jenkins node VM в отключенный моментальный снимок
сообщите хозяину, что агент node отключен (поскольку мастер, похоже, автоматически не замечает, что агент выключен, всякий раз, когда я возвращаю или сильно отключает свои виртуальные машины)
включить агент node VM обратно
как "действие после сборки", запустите отдельное задание, ограниченное для запуска на агенте node VM

Я выполняю шаг отключения агента с запросом POST для завивки, но может быть более чистый способ сделать это:

curl -d "offlineMessage=&json=%7B%22offlineMessage%22%3A+%22%22%7D&Submit=Yes" http://JENKINS_HOST/computer/THE_NODE_TO_DISCONNECT/doDisconnect

Затем, когда я загружаю агент node, агент запускает и автоматически соединяется, и мастер замечает, что агент снова подключен к сети (и затем отправит его задания).

Я также смог включить и отключить доступ к node с помощью этой команды (используя 'toggleOffline' вместо 'doDisconnect'):

curl -d "offlineMessage=back_in_a_moment&json=%7B%22offlineMessage%22%3A+%22back_in_a_moment%22%7D&Submit=Mark+this+node+temporarily+offline" http://JENKINS_HOST/computer/NODE_TO_DISCONNECT/toggleOffline

(Выполнение этой же команды снова возвращает статус node.)

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

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