Usando Hudson y construyendo pasos con múltiples repositorios de git

Question

Estoy intentando que Hudson reemplace 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 compilar project_a agregué un nuevo trabajo con varios repositorios de git (los de arriba). Quería que Hudson clonara los repositorios en directorios diferentes en $ WORKSPACE , porque el 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? ¿Debo crear un repositorio local de git con todos los proyectos como submódulos de git o algo así?

Answer 1

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

---

Configuración del encadenamiento

En la configuración de trabajo del proyecto, desplácese hacia abajo hasta Acciones posteriores a la creación y marque Generar otros proyectos ... Ingrese en test_framework como el proyecto a construir.

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

---

Cómo funciona

Lo que ha configurado ahora es project_a sondeará el SCM en busca de cambios, cuando se encuentren cambios los sacará de git. Ejecute los pasos de compilación (si los hay) y, al finalizar, active el trabajo test_framework para extraer los cambios de git (si los hay) y ejecute los pasos de compilación.

Answer 2

El problema con el " Crear otros proyectos " la solución es que si hay cambios en test_framework, no se activará project_a para compilar. En su lugar, recomiendo abandonar el complemento git y configurar un " Ejecutar shell " paso de compilació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, cree los 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, cada vez que se envíen cambios a cualquiera de los dos repositorios, el gancho usará la API de Hudson para desencadenar una compilación.

Answer 3

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 estar funcionando realmente bien (aunque es un poco complicada). La mayor parte del crédito de esta solución debe ir 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) Cree 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 fuente. 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 o no importar (usted sabe mejor que yo), pero la tarea sin control de fuente debería ser el último eslabón de la cadena.

Answer 4

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

Por lo tanto, project_a copiaría los últimos artefactos estables que necesita de test_framework y una actualización al marco de prueba activaría una compilación en project_a. proyecto_a aún puede ser activado por un cambio en Git, simplemente copia de nuevo los artefactos más recientes en test_framework.

Answer 5

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

---

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

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