Перенастройте и перезагрузите Hudson / Подчиненное устройство Jenkins как часть сборки
У меня есть установка сервера Jenkins (Hudson), которая запускает тесты на различных подчиненных машинах. Я хочу перенастроить ведомое устройство (используя удаленные API), перезагрузить ведомое устройство, чтобы изменения вступили в силу, а затем продолжить оставшуюся часть теста. До сих пор я сталкивался с двумя препятствиями:
- Как только задание Jenkins начинает выполняться на ведомом устройстве, ведомое устройство не может выйти из строя или разорвать сетевое соединение с сервером, в противном случае Jenkins немедленно не пройдет тест. Обычно я бы сказал, что это совершенно желательное поведение. Но в этом случае я бы хотел, чтобы Дженкинс принял нарушение, пока подчиненное устройство не вернется в сеть и Дженкинс не сможет повторно подключиться к нему - или пока подчиненное устройство не подключится к Дженкинсу.
- В задании, которое было прикреплено к ведомому устройству, мне нужно выполнить некоторые задачи сборки на ведущем устройстве Jenkins, а не на ведомом устройстве.
Возможно ли это? Пока я не нашел способа сделать это с помощью Jenkins или каких-либо его плагинов.
EDIT - дополнительное объяснение Мне очень, очень нравится рабская архитектура Дженкинса. В сочетании с уже доступными плагинами он позволяет очень легко передавать задания ведомому устройству, запускать и получать результаты обратно. А возможность выбора любого подходящего подчиненного устройства позволяет выполнять автоматическое распределение заданий / тестов.
В нашей ситуации мы используем виртуализированные (VMware) подчиненные машины. Было достаточно просто написать сценарий, который заставил бы Дженкинс использовать VMware PowerCLI для запуска виртуальной машины, когда ей нужно было работать на ведомом устройстве, а затем отправить ему задание и получить результаты обратно. Все хорошо.
ИСКЛЮЧАЯ Часть настройки каждого теста заключается в том, чтобы каким-то образом немного изменить конфигурацию виртуальной машины. Отключите UAC, войдите в систему как другой пользователь, установите другой драйвер и т. Д. - каждое из этих изменений требует перезагрузки тестовой виртуальной машины / ведомого устройства, прежде чем изменения вступят в силу. Хотя я могу писать сценарии подчиненного устройства по требованию (метод запуска = Запуск подчиненного устройства посредством выполнения команды на главном устройстве), которые обрабатывают эту реконфигурацию и перезапуск, это должно быть выполнено ДО запуска задания. Вот где возникает проблема - я не могу настроить ведомое устройство так рано, потому что тип изменений конфигурации зависит от выполняемого задания, что происходит только после запуска ведомого устройства.
Возможные решения
1) Используйте несколько подчиненных экземпляров на одной виртуальной машине. Это не сработает - некоторые конфигурации являются взаимоисключающими, но Дженкинс этого не знает. Таким образом, он будет пытаться запустить одну ведомую конфигурацию для одного задания, другой ведомый для другого задания - и оба ведомых устройства будут на одной виртуальной машине. Блокировка заданий не предотвращает этого, поскольку запуск ведомого устройства не является частью работы.
2) (Оптимально) Шаг сборки, который позволяет заданию узнать, что его подчиненное соединение МОЖЕТ быть прервано. На этапе сборки может потребоваться включить некоторые параметры, чтобы Дженкинс знал, как повторно подключить подчиненное устройство (будет ли подчиненное устройство повторно подключаться автоматически, должен ли Дженкинс запустить сценарий, будет достаточно простого SSH). Этап сборки обрабатывает отключение ведомого устройства, игнорирует отключение, обычно приводящее к сбою задания, а затем выполняет повторное подключение. После того, как ведомое устройство восстановлено и запущено, может произойти следующий этап сборки. Возможно, истекло время ожидания для сбоя задания, если ведомое устройство не может повторно подключиться в течение определенного времени.
** Текущее решение ** - менее чем оптимальное
На этапе сборки может потребоваться включить некоторые параметры, чтобы Дженкинс знал, как повторно подключить подчиненное устройство (будет ли подчиненное устройство повторно подключаться автоматически, должен ли Дженкинс запустить сценарий, будет достаточно простого SSH). Этап сборки обрабатывает отключение ведомого устройства, игнорирует отключение, обычно приводящее к сбою задания, а затем выполняет повторное подключение. После того, как ведомое устройство восстановлено и запущено, может произойти следующий этап сборки. Возможно, истекло время ожидания для сбоя задания, если ведомое устройство не может повторно подключиться в течение определенного времени.
** Текущее решение ** - менее оптимально
На этапе сборки может потребоваться включить некоторые параметры, чтобы Дженкинс знал, как повторно подключить подчиненное устройство (будет ли подчиненное устройство повторно подключаться автоматически, должен ли Дженкинс запустить сценарий, будет достаточно простого SSH). Этап сборки обрабатывает отключение ведомого устройства, игнорирует отключение, обычно приводящее к сбою задания, а затем выполняет повторное подключение. После того, как ведомое устройство восстановлено и запущено, может произойти следующий этап сборки. Возможно, истекло время ожидания для сбоя задания, если ведомое устройство не может повторно подключиться в течение определенного времени.
** Текущее решение ** - менее оптимально
Прямо сейчас я не могу использовать подчиненную функцию Jenkins. Вместо этого я использую серию этапов сборки - запускаемых на главном сервере - с использованием сценариев Windows и PowerShell для включения виртуальной машины, выполнения настроек и перезапуска. На виртуальной машине работает SSH-сервер, и я использую его для загрузки тестовых файлов на тестовую виртуальную машину, а затем их удаленного выполнения. Затем загрузите результаты обратно в Jenkins для обработки заданием. Это решение функционально, но требует гораздо больше работы, чем типичный подход Jenkins slave. Кроме того, сценарии нацелены на одну виртуальную машину; Мне нелегко использовать пул рабов.