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

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

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

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

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

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

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

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

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