Jenkins y trabajos de configuración múltiple(matriz)

continuous-integration multi-configuration (9)

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

Algunas razones vienen a la mente:

Porque los trabajos deberían ser fáciles de crear y configurar. Si es difícil configurar un trabajo en su entorno, probablemente esté haciendo algo mal fuera del alcance del trabajo de jenkins. Si está contento de que haya logrado crear ese único trabajo y finalmente se ejecuta, y usted es reacio a hacer todo este trabajo nuevamente, ahí es donde debería intentar mejorar.
Porque los trabajos de configuración múltiple son más complejos. Por lo general, requieren que pienses tanto en el trabajo principal como en las diferentes variables del sub trabajo, y tienden a crecer en complejidad hasta un nivel más allá de ser manejable. Por lo tanto, en un único escenario de trabajo, probablemente desperdicie pensamientos de no usar esa complejidad, y al extender las variables de compilación, las cosas podrían crecer en la dirección incorrecta. Sugiero usar los trabajos simples como predeterminados, y los trabajos de configuración múltiple solo si hay una necesidad de configuraciones múltiples.
Debido a que la ejecución de trabajos de configuración múltiple puede necesitar más ranuras de trabajo en los esclavos que los trabajos individuales. Siempre habrá un trabajo maestro que se ejecuta en una ranura especial e invisible (eso no es un problema en sí mismo) y desencadena los trabajos secundarios, pero si estos trabajos secundarios desencadenan sub trabajos, puede terminar fácilmente en un punto muerto si hay más trabajos secundarios que máquinas tragamonedas, y algunos trabajos secundarios activan de nuevo sub trabajos que luego no se pueden ejecutar porque no hay más espacios disponibles. Este problema se puede eludir mediante el uso de alguna configuración de 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 algo más complejo, y debido a que la complejidad debe evitarse a menos que sea necesario, el trabajo de estilo libre regular es un mejor predeterminado.

¿Por qué hay dos tipos de trabajos para Jenkins, tanto el proyecto de configuración múltiple como el proyecto de proyecto de estilo libre? Leí en alguna parte que una vez que eliges uno de ellos, no puedes convertir el otro (fácilmente). ¿Por qué no elegiría siempre el proyecto de configuración múltiple para estar seguro de futuros cambios?

Me gustaría configurar una compilación para la construcción de un proyecto tanto en Windows como en Unix (y otras plataformas también). Encontré esta pregunta ), que pregunta lo mismo, pero realmente no entiendo la respuesta. ¿Por qué necesitaría tres proyectos de matriz (y no tres proyectos de estilo libre), uno para cada plataforma? ¿Por qué no puedo mantenerlos todos en una matriz, con plataformas Y (por ejemplo) versión de gcc en un eje y (mi) versiones de software en el otro?

También leí esta publicación de blog , pero eso crea todo en la misma máquina, con solo diferentes versiones de Python.

Entonces, en resumen: ¿cómo configura la mayoría de las personas un proyecto de configuración múltiple que apunta a muchas plataformas diferentes?

Los dos tipos de trabajos tienen funciones separadas:

Trabajos de estilo libre: estos le permiten construir su proyecto en una sola computadora o etiqueta (grupo de computadoras, por ejemplo, "Windows XP 32").
Trabajos de configuración múltiple: estos le permiten construir su proyecto en múltiples computadoras o etiquetas, o una combinación de ambos, por ejemplo, Windows XP, Windows Vista, Windows 7 y Red Hat, lo que resulta útil para verificar la compatibilidad o crear múltiples plataformas (¿programas qt?)

Si tiene un proyecto que desea construir en Windows y Unix, tiene dos opciones:

Cree un trabajo independiente de estilo libre para cada configuración, en cuyo caso debe mantener cada uno individualmente
Tiene un trabajo de configuración múltiple y selecciona 2 (o más) etiquetas / computadoras / esclavos: 1 para Windows y 1 para Unix. En este caso, solo debe mantener un trabajo para la construcción

Puede mantener las versiones de su gcc en un eje y las versiones de software en otro. No hay ninguna razón por la que no puedas.

La pregunta que vincula tiene un punto justo, pero que no se relaciona directamente con su pregunta: en su caso, tenía un trabajo de configuración múltiple A , que, en caso de éxito, desencadenaba otro trabajo B. Ahora, en un trabajo de configuración múltiple, si una de las configuraciones falla, todo el trabajo falla (obviamente, ya que desea que su proyecto se construya con éxito en todas sus configuraciones).

En mi humilde opinión, para construir el mismo proyecto en múltiples plataformas, la mejor manera de hacerlo es utilizar un trabajo de estilo de configuración múltiple.

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

Podría usar la variable que crea jenkins 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). Luego crea dos pasos de compilación separados y busca la variable de entorno OSTYPE.

En su lugar, 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.

Puede crear un script (por ejemplo, compilación ) y un archivo por lotes (por ejemplo, build.bat ) que se verifique con su código fuente. En Jenkins, en su etapa de compilación, puede llamar a $ WORKSPACE / build : Windows ejecutará build.bat, mientras que Linux ejecutará build .

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, Los he probado todos (el complemento Tie funciona solo para el trabajo maestro, Restringir en Opciones Avanzadas del Proyecto no es un activador seguro para la roca, así que quiere usar un eje esclavo que hoy funciona correctamente).

Si vas a la ruta matricial 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 le dice a XShell que ejecute "build". El correcto se ejecutará en cada caso.

Un truco para que los archivos por lotes se ejecuten en Windows y las secuencias de comandos del shell en Unix:

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

ln -s /bin/true /bin/cmd

En Windows, encuentre un true.exe , true.exe nombre sh.exe y colóquelo en algún lugar de la RUTA.

Alternativamente, si tienes sh.exe instalado en Windows (de Cygwin, Git u otro origen), sh.exe a la parte superior del script de shell en Jenkins:

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

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

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