Jenkins: ¿Cómo construir múltiples proyectos de nivel superior desde un repositorio de git?

Question

Tengo un repositorio de Git que contiene un montón de proyectos maven de alto nivel (cada uno se sienta en su propio subdirectorio con un pom.xml). El nivel superior aquí significa que estos proyectos se encuentran en el subdirectorio directamente debajo de la raíz del repositorio. Todos estos proyectos deben permanecer en el mismo repositorio de Git.

repo 
+--- projectA 
    +--- pom.xml 

+--- projectB 
    +--- pom.xml 

Pueden/deben construirse por trabajos independientes de jenkins. Entonces tenemos un trabajo para projectA y uno para projectB.

Anteriormente con Subversion pude configurar un trabajo de Jenkins (para cada proyecto) que solo obtenía el origen del proyecto y ejecutaba una compilación de Maven desde el pom.xml.

Con el modelo Git (probablemente lo mismo con todos los DVCS) esto cambia y no estoy seguro de cuál es la mejor práctica. Hay algunas opciones que veo y de la que no me gustan:

1. Cada trabajo de Jenkins es configured para clonar/tire el repositorio Git completa y se refiere a la /pom.xml para la construcción de Maven. Entonces, el trabajo tiene todo el código, pero construye solo una porción del mismo.
2. Git ofrece submódulos (http://book.git-scm.com/5_submodules.html) que parecen ser un poco difícil de manejar (y puede romperse con facilidad)
3. Crear un padre experto (agregador que contiene todos los proyectos) proyecto que desencadena cada proyecto de construcción (que tiene un solo trabajo jenkins). Este pom.xml contiene elementos para projectA y projectB.

¿Ven algún enfoque más útil para esto (configuración muy típica). ¿Cuál es tu experiencia? ¿Alguna mejor práctica?

Answer 1

Creo que estás trabajando a contrapelo aquí. Si estos proyectos se lanzan como una unidad versionada, deberías crear un POM padre. Pero probablemente solo deberías tener un solo trabajo de CI. Si desea que la compilación avance rápidamente, puede configurarla para que solo genere módulos que hayan cambiado desde la última compilación (botón avanzado en la sección Generar - "Incremental compilación - solo compilación cambia módulos"). También puede indicarle a Jenkins "Ejecutar construcciones simultáneas si es necesario" para probar varias confirmaciones a la vez.

Pero me pregunto por qué piensas que quieres múltiples trabajos de CI? Si percibes que estos dos proyectos tienen ciclos de vida diferentes, tal vez deberían ser versionados por separado y, por lo tanto, deberían estar en repositorios git separados. No conserves repositorios git, son baratos. De hecho, cuanto más, mejor en casi todos los casos.

Por lo general, desea que un pom determinado produzca un solo artefacto. Los poms agregadores son útiles para dividir partes de un artefacto más grande en submódulos, pero solo si esos submódulos no se liberan por sí solos.

Answer 2

Bueno, existe la mejor práctica de no repetirse. Entonces, tener un súper POM sería bueno desde ese punto de vista.

Id probablemente vaya con la opción 1. El espacio en disco suele ser barato.

Pero 3 facilitaría la implementación en sistemas nuevos, sin necesidad de volver a configurar Jenkins.

Answer 3

@recampbell, tengo el mismo problema. Tenemos varios proyectos interrelacionados en un único repositorio Hg.

De esta manera, sabemos exactamente bajo qué versión (número de versión hg), compilar entre sí. Cuando digo exactamente, me refiero a que puedo verificar que es binario idéntico.

El uso de números de versión es demasiado grueso. Por ejemplo, hoy encontré un error reproducible solo bajo la versión hg 3367 pero no en hg versión 3368. Usar múltiples repositorios hg que no hubieran sido reproducibles, ya que hay varios compromisos en cada uno de los proyectos cada día, y por lo tanto es imposible determinar exactamente qué versión de cada proyecto individual se usó, solo la versión de hg es la correcta para usar (usando bisección para encontrar el error).

Resultó que habíamos cambiado la versión del controlador de la base de datos del cliente en uno de los subproyectos y eso hizo que nuestra generación automatizada de datos fallara con un NPE. El controlador, por supuesto, si una versión de lanzamiento que no escribimos, simplemente utilizamos la proporcionada por el proveedor. Nos habría llevado varios días depurar esto, pero como utilizamos Jenkins para construir cada hora, sabíamos que había entre 10 y 20 intentos de búsqueda, y solo 3 o 4 tocaron el dao-generador, por lo que fue una tarea fácil.

Tener versiones mixtas de cada proyecto habría sido un dolor en la parte trasera inferior, ya que tendríamos varios dao-generator-3.1.2.jar diferentes que serían un poco diferentes uno del otro (a menos que ¿Esperamos que cambiemos los números de versión después de cada confirmación, o si hay alguna configuración en Jenkins/maven/lo que sea que haga esto automáticamente? eso sería genial ...).