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

Question

¿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é this question), que pregunta lo mismo, pero realmente no recibo 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 leo this blog post, pero eso construye todo en la misma máquina, con solo diferentes versiones de Python.

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

Answer 1

Los dos tipos de puestos de trabajo tienen funciones separadas:

• empleos de estilo libre: éstos le permiten construir su proyecto en una sola computadora o etiqueta (grupo de equipos, 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 RedHat, , útiles para verificar la compatibilidad o edificio para múltiples plataformas (programas qt?)

Si usted tiene un proyecto que se quiere construir en Windows & Unix, tiene dos opciones:

• crear un trabajo de estilo libre separado para cada configuración, en cuyo caso debe mantener cada una individualmente
• Tiene un trabajo de varias configuraciones, 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 compilación

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

La pregunta que enlace tiene un punto justo, pero que no esté relacionada con su pregunta directamente: en su caso, él tenía un trabajo de configuración múltiple Un, que - en caso de éxito - desencadenó 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.

Answer 2

Puede 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 utilizar un lenguaje de scripts 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.

Answer 3

Se puede crear un guión (por ejemplo acumulación) y un archivo por lotes (por ejemplo build.bat) que consiguen puso en contacto con su código fuente. En Jenkins en su etapa de compilación puede llamar al $ WORKSPACE/build - Windows ejecutará build.bat mientras que Linux ejecutará compilación.

Answer 4

Otra opción es utilizar 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.

Answer 5

Si va por la ruta matricial con Windows y otra cosa, querrá 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.

Answer 6

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 (cáscara Executar, comandos de Windows, ...)

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

Answer 7

un truco para tener los archivos por lotes se ejecutan en Windows y las secuencias de comandos del 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, o bien encontrar un true.exe, nombre que sh.exe y colocarlo en algún lugar en el PATH.

Alternativamente, si usted tiene cualquier sh.exe instalado en Windows (De Cygwin, Git, u otra fuente), añadir esto a la parte superior de la secuencia de comandos shell en Jenkins:

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

Answer 8

¿Por qué no lo haría siempre elige el tipo de trabajo de configuración múltiple?

Algunas de las razones vienen a la mente:

1. Dado que los trabajos deben 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.
2. 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.
3. Porque la ejecución de trabajos de configuración múltiple puede necesitar más ranuras de trabajo en los esclavos que trabajos únicos. 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.

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 valor predeterminado.

Answer 9

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 disparador seguro para que también quiera usar el eje esclavo que hoy funciona correctamente).