Uso de Hudson y pasos de compilación con múltiples repositorios de git

Question

Estoy probando con Hudson para reemplazar nuestra configuración actual de Buildbot. Instalé el plugin git. Nuestra configuración actual es como:

ssh://server:/repo/test_framework.git 
ssh://server:/repo/project_a.git 

Ahora, para construir project_a he añadido un nuevo trabajo con múltiples repositorios git (los de arriba). Quería que Hudson clonara los repositorios en diferentes directorios bajo $WORKSPACE, porque test_framework necesita esa jerarquía. Pero Hudson parece fusionar todo en $WORKSPACE en su lugar. Desde el registro de la consola:

warning: no common commits 
... 
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 96d2b3c27595de243702414c4358366923696d78 
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 5bb011b3fa288afd5e4392640b32b8bcc982103e 
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 aa6ade81669883909ba5f5459a205df1bd0df3c0 

¿Puedo configurar esto en Hudson para que se ajuste mejor a la configuración de nuestro proyecto? ¿Necesito crear un repositorio de git ficticio local con cada proyecto como submódulos de Git o algo así?

Answer 1

Dentro de Hudson puede encadenar varios trabajos juntos. Puede intentar crear trabajos de Hudson por separado para test_framework y otro para project_a. Hudson crea un directorio separado en $ WORKSPACE para cada trabajo, por lo que ahora debe tener dos directorios diferentes en $ WORKSPACE.

---

de configuración de encadenamiento

En la configuración del trabajo de desplazamiento hacia abajo para project_a posterior a la generación acciones y comprobar construir otros proyectos ... Introduzca en test_framework como el proyecto de construcción.

En la configuración del trabajo de test_framework, asegúrese de que Poll SCM esté sin marcar y que Build después de otros proyectos esté configurado en project_a.

---

Cómo funciona

Lo que ahora ha configurado es project_a sondeará el SMC en busca de cambios, cuando se encontraron cambios que se tire de ellas git. Ejecute los pasos de compilación (si corresponde) y al finalizar active el trabajo test_framework para extraer los cambios de git (si corresponde) y ejecutar sus pasos de compilación.

Answer 2

El problema con la solución "Crear otros proyectos" es que si hay cambios en test_framework no se activará project_a build. En lugar de ello, recomiendo abandonar el plugin git y la creación de un paso "Ejecutar shell" acumulación con lo siguiente:

rm -rf ${WORKSPACE}/* 

git clone ssh://server:/repo/test_framework.git ${WORKSPACE}/test_framework 
cd ${WORKSPACE}/test_framework 
git fetch -t ssh://user@server:/repo/test_framework.git +refs/heads/*:refs/remotes/origin/* 
git ls-tree HEAD 

git clone ssh://server:/repo/project_a.git ${WORKSPACE}/project_a 
cd ${WORKSPACE}/project_a 
git fetch -t ssh://user@server:/repo/project_a.git +refs/heads/*:refs/remotes/origin/* 
git ls-tree HEAD 

A continuación, crear archivos de gancho "servidor: /repo/test_framework.git/hooks/post-receive" y "servidor: /repo/project_a.git/hooks/post-receive" con el siguiente contenido:

#!/bin/sh 
curl http://hudson/job/job_name/build 

Ahora, cuando los cambios son empujados a cualquier repositorio, el gancho va a utilizar la API de Hudson para desencadenar una acumulación.

Answer 3

Me encontré con el mismo problema y actualmente lo solucioné creando un trabajo para cada proyecto y usando Copy Artifact Plugin para permitir construir el trabajo dependiente incluso si se hace una actualización de Git en sus dependencias (esto es para evitar construir en el medio de una actualización del proyecto del que dependemos).

Así que project_a copiará los últimos artefactos estables que necesita de test_framework y una actualización de test framework desencadenaría una construcción en project_a.project_a aún puede ser activado por un cambio en Git, simplemente copia nuevamente los últimos artefactos en test_framework.

Answer 4

Me doy cuenta de que esta pregunta es muy antigua, pero me encontré con el mismo problema y usé esta página para desarrollar mi propia solución que parece funcionar muy bien (aunque es un poco intrincada). La mayor parte del crédito por esta solución debería corresponder a Clinton (la única razón por la que me molesto en enviar esta respuesta es porque su respuesta no parece abordar múltiples repositorios que deben estar en el mismo directorio base).

Supongamos que tiene dos repositorios (A y B).

Pasos:

1) Hacer dos proyectos para tirar de los repositorios de código remoto A y B. poner cualquier pasos de generación necesarios en cualquier repositorio.

2) Cree un tercer directorio sin ninguna gestión de control de origen. Añadir un paso de generación de este proyecto para ejecutar un comando shell similar a esto: (. Sus caminos no pueden ser los mismos Búscalos usted mismo!)

ln -s /var/lib/jenkins/jobs/A/workspace A 
ln -s /var/lib/jenkins/jobs/B/workspace B 

Ahora puede añadir cualquier otra etapa de construcción que dependen de que A y B sean hermanas en un directorio. ¡Yay enlaces simbólicos!

3) Encadena las tres tareas juntas. El orden de las tareas de extracción puede importar o no (usted sabe mejor que yo) pero la tarea sin control de fuente debe ser el último eslabón de la cadena.

Answer 5

El problema que describes ya se presentó como error en el bugtracker Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-8082

---

Nosotros usamos la opción "espacio de trabajo personalizado" en la configuración del trabajo de proyecto ampliado a la caja de depósito de nuestro trabajo en un subdirectorio de otro trabajo.

Eso otras comprobaciones de trabajo fuera del directorio principal con todos los submódulos:

var/lib/jenkins/jobs/ 
    + main_job 
    + workspace (main git checkout with submodules) 
     + modules 
     + mod1 
     + mod2 
    + mod1_job (custom workspace set to main_job/workspace/modules/mod1) 
    + workspace (empty)