Tengo una configuración de servidor Jenkins (Hudson) que ejecuta pruebas en una variedad de máquinas esclavas. Lo que quiero hacer es reconfigurar el esclavo (usando API remotas), reiniciar el esclavo para que los cambios surtan efecto y luego continuar con el resto de la prueba. Hay dos obstáculos que he encontrado hasta ahora:

Una vez que un trabajo de Jenkins comienza a ejecutarse en el esclavo, el esclavo no puede fallar o interrumpir la conexión de red al servidor; de lo contrario, Jenkins falla inmediatamente la prueba. Normalmente, diría que este es un comportamiento completamente deseable. Pero en este caso, me gustaría que Jenkins acepte la interrupción hasta que el esclavo vuelva a conectarse y Jenkins pueda volver a conectarse a él, o el esclavo se vuelva a conectar a Jenkins.En un trabajo que se ha adjuntado al esclavo, necesito ejecutar algunas tareas de compilación en el maestro Jenkins, no en el esclavo.

¿Es posible? Hasta ahora, no he encontrado una manera de hacer esto usando Jenkins o cualquiera de sus complementos.

EDIT - Explicación adicional Realmente me gusta mucho la arquitectura esclava de Jenkins. Combinado con los complementos ya disponibles, hace que sea muy fácil llevar trabajos a un esclavo, ejecutarlos y los resultados se retiraron. Y la capacidad de elegir cualquier esclavo compatible permite la distribución automática de trabajos / pruebas.

En nuestra situación, utilizamos máquinas esclavas virtualizadas (VMware). Fue bastante fácil escribir una secuencia de comandos que haría que Jenkins usara VMware PowerCLI para iniciar la VM cuando necesitaba ejecutarse en un esclavo, luego enviar el trabajo y devolver los resultados. Todo bien

EXCEPT Parte de la configuración de cada prueba es reconfigurar ligeramente la máquina virtual de alguna manera. Inhabilite UAC, inicie sesión como un usuario diferente, tenga un controlador diferente instalado, etc. Cada uno de estos cambios requiere que la máquina virtual / esclavo de prueba se reinicie antes de que los cambios surtan efecto. Aunque puedo escribir scripts esclavos a pedido (Método de lanzamiento = Lanzar esclavo mediante la ejecución del comando en el maestro) que manejan esta reconfiguración y reinicio, debe hacerse ANTES de ejecutar el trabajo. Ahí es donde ocurre el problema: no puedo configurar el esclavo tan temprano porque el tipo de cambios de configuración dependen del trabajo que se ejecuta, lo que ocurre solo después de que se inicia el esclavo.

Soluciones posible
1) Use varias instancias esclavas en una sola VM. Esto no funcionaría: varias de las configuraciones son mutuamente excluyentes, pero Jenkins no lo sabe. Por lo tanto, intentaría iniciar una configuración de esclavo para un trabajo, otro esclavo para un trabajo diferente, y ambos esclavos estarían en la misma máquina virtual. Los bloqueos en los trabajos no evitan esto, ya que el arranque esclavo no es parte del trabajo.

2) (Óptimo) Un paso de compilación que permite que un trabajo sepa que su conexión esclava PUEDE interrumpirse. El paso de compilación puede tener que incluir algunas opciones para que Jenkins sepa cómo volver a conectar el esclavo (el esclavo se volverá a conectar automáticamente, Jenkins tendrá que ejecutar un script, será suficiente con SSH). El paso de compilación manejaría la desconexión del esclavo, ignoraría la desconexión que normalmente falla en el trabajo y luego realizaría la reconexión. Una vez que el esclavo vuelve a estar en funcionamiento, puede ocurrir el siguiente paso de compilación. Tal vez un tiempo de espera para fallar el trabajo si el esclavo no se puede volver a conectar en un cierto período de tiempo.

** Solución actual ** - menos que óptima
Ahora mismo, no puedo usar la función esclava de Jenkins. En cambio, utilizo una serie de pasos de compilación, ejecutados en el maestro, que usan scripts de Windows y PowerShell para encender la VM, realizar las configuraciones y reiniciarla. La VM tiene un servidor SSH ejecutándose y lo uso para cargar archivos de prueba a la VM de prueba, luego los ejecuto de forma remota. Luego descargue los resultados a Jenkins para que los maneje el trabajo. Esta solución es funcional, pero requiere mucho más trabajo que el típico enfoque esclavo de Jenkins. Además, los scripts están dirigidos a una sola VM; No puedo usar fácilmente un grupo de esclavos.