Trabajos Jenkins y multi-configuración (matrix)

Otra opción es usar un paso de compilación de python para verificar el sistema operativo actual y luego llamar a un script de configuración o compilación apropiado. En el script python, puede guardar el entorno actualizado en un archivo e inyectar el entorno de nuevo utilizando el complemento EnvInject para los pasos de compilación posteriores. Dependiendo del tamaño de su entorno de compilación, también podría usar una herramienta de compilación multiplataforma como SCons.

Una opción es usar el eje definido por el usuario combinado con esclavos (windows, linux,...), por lo que necesita agregar un filtro para cada combinación y usar el plugin Condicional BuildStep para establecer el paso de compilación específico para cada plataforma(Executar shell, Windows command,...)

Este enlace tiene un tutorial, pero está en portugués, pero es fácil de trabajar en base a la imagen... http://manhadalasanha.wordpress.com/2013/06/20/projeto-de-multiplas-configuracoes-matrix-no-jenkins/

Puede crear un script (por ejemplo, build) y un archivo por lotes (por ejemplo, build.bat) que se registran con su código fuente. En Jenkins en tu paso de compilación puedes llamar a WORKSPACE WORKSPACE/build - Windows ejecutará build.bat mientras que Linux ejecutará build.

Puede usar la variable que jenkins crea cuando define un eje de matriz de configuración. Por ejemplo: Crea un eje esclavo con el nombre OSTYPE y comprueba los dos esclavos (Windows y Linux). A continuación, cree dos pasos de compilación separados y compruebe la variable de entorno OSTYPE.

Podría usar un lenguaje de script mejorado, como python, que es multiplataforma y puede lograr la misma funcionalidad independientemente del nombre de los esclavos y en un solo paso de compilación.

Si vas por la ruta de la matriz con Windows y algo más, querrás el complemento XShell. Usted acaba de crear sus dos scripts de compilación como " build.bat "para cmd y "build" para bash, y dile a XShell que ejecute "build". La correcta se ejecutará en cada caso.

Un truco para ejecutar archivos por lotes en Windows y scripts de shell en Unix:

En Unix, haga que los archivos por lotes salgan con 0 estado de salida:

ln -s /bin/true /bin/cmd

En Windows, busca un true.exe, nómbralo sh.exe y colócalo en algún lugar de la RUTA.

Alternativamente, si tiene algún sh.exe instalado en Windows (Desde Cygwin, Git u otra fuente), agregue esto a la parte superior del script de shell en Jenkins:

[ -n "$WINDIR" ] && exit 0

¿Por qué no elegirías siempre el tipo de trabajo de configuración múltiple?

Algunas razones vienen a la mente:

1. Porque los trabajos deben ser fáciles de crear y configurar. Si es difícil configurar cualquier trabajo en su entorno, es probable que esté haciendo algo mal fuera del alcance del trabajo de jenkins. Si estás contento de haber logrado crear ese trabajo y finalmente funciona, y eres reacio a hacer todo este trabajo de nuevo, ahí es donde deberías tratar de mejorar.
2. Porque los trabajos de configuración múltiple son más complejos. Por lo general, requieren que piense tanto en el trabajo principal como en las diferentes variables de trabajo secundario, y tienden a crecer en complejidad hasta un nivel más allá de ser manejables. Así que en un solo escenario de trabajo, probablemente desperdiciarías pensamientos en no usar esa complejidad, y al extender las variables de compilación, las cosas podrían crecer en la dirección equivocada. Sugeriría usar los trabajos simples como predeterminados, y los trabajos de configuración múltiple solo si hay una necesidad de múltiples configuraciones.
3. Porque ejecutar trabajos de configuración múltiple podría necesitar más espacios de trabajo en los esclavos que trabajos individuales. Siempre habrá un trabajo maestro que se ejecuta en una ranura especial e invisible (eso no es un problema por sí mismo) y desencadena los trabajos secundarios, pero si estos trabajos secundarios desencadenan por sí mismos trabajos secundarios, puede terminar fácilmente en un punto muerto si hay más trabajos secundarios que espacios, y algunos trabajos secundarios activan nuevamente trabajos secundarios que luego no pueden ejecutarse porque no hay más espacios abiertos. Este problema puede ser eludido usando alguna configuración en los esclavos, pero está presente y solo puede ocurrir si varios trabajos múltiples se ejecutan simultáneamente.

Así que en esencia: El trabajo de configuración múltiple es una cosa más compleja, y debido a que la complejidad debe evitarse a menos que sea necesario, el trabajo de estilo libre regular es un mejor valor predeterminado.

Si desea seleccionar en qué esclavo ejecuta el trabajo, debe usar el proyecto de configuración múltiple (de lo contrario, no podrá seleccionar/limitar los esclavos en los que lo ejecuta-hay tres formas de hacerlo, sin embargo, las he probado todas (El complemento Tie funciona solo para el trabajo maestro, Restringir en las Opciones Avanzadas del proyecto no es un disparador seguro, así que desea usar el eje esclavo que se ha demostrado que funciona correctamente hoy.)