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

git push tag

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 agregué un nuevo trabajo con múltiples repositorios git (los de arriba). Quería que Hudson $WORKSPACE los repositorios en diferentes directorios bajo $WORKSPACE , test_framework necesita esa jerarquía. Pero Hudson parece fusionar todo en $WORKSPACE en $WORKSPACE 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 múltiples 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.

Configurar encadenamiento

En la configuración del trabajo del proyecto, desplácese hacia abajo a las acciones posteriores a la creación y marque Compilar otros proyectos ... Ingrese en test_framework como el proyecto para compilar.

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

Cómo funciona

Lo que ha configurado ahora es que project_a sondeará el SCM en busca de cambios; cuando se encuentren cambios, los sacará de 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 cambio, recomiendo abandonar el plugin git y configurar un paso de compilación "Ejecutar shell" 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, cree los archivos hook "server: /repo/test_framework.git/hooks/post-receive" y "server: /repo/project_a.git/hooks/post-receive" con el siguiente contenido:

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

Ahora, cada vez que los cambios se envían a cualquiera de los repositorios, el enlace utilizará la API de Hudson para activar una compilación.

Answer 3

El problema que está describiendo ya está archivado como un error en el rastreador de errores de Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-8082

Utilizamos la opción de "espacio de trabajo personalizado" en la configuración de trabajo del proyecto extendido para verificar el repositorio de nuestro trabajo en un subdirectorio de otro trabajo.

Ese otro trabajo revisa el 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)

Answer 4

Me doy cuenta de que esta pregunta es muy antigua, pero me encontré con el mismo problema y utilicé esta página para desarrollar mi propia solución que parece funcionar muy bien (aunque es un poco complicada). 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) Realice dos proyectos para extraer el código de los repositorios remotos A y B. Coloque los pasos de compilación necesarios en cualquiera de los repositorios.

2) Cree un tercer directorio sin ninguna gestión de control de origen. Agregue un paso de compilación a este proyecto para ejecutar un comando de shell similar a este:

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

(Tus caminos pueden no ser los mismos. ¡Búscalos tú mismo!)

Ahora puede agregar cualquier otro paso de compilación que dependa 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

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

Entonces project_a copiaría los últimos artefactos estables que necesita de test_framework y una actualización para probar 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.