2012-03-28 16 views
28

Tengo un repositorio de GitHub que es grande y contiene varias piezas de construcción independientes. Si configuro Jenkins con un trabajo (o dos) para cada uno de estos, termino teniendo que extraer gigabytes de datos varias veces (un clon del repositorio para cada trabajo).¿Cómo puedo obtener varias versiones de Jenkins para trabajar desde un repositorio git local?

Esto requiere espacio de disco y ancho de banda.

Lo que me gustaría hacer es tener el trabajo "Refresh local repo" que clona github una vez, luego configure cada uno de los trabajos para clonarlos a partir de ese repositorio y compilar. Luego, al configurar los subtrabajos como compilaciones dependientes, puedo ejecutar "Refresh local repo", hacer que extraiga todo lo último de GitHub y luego ejecutar cada compilación.

Hasta ahora tengo el trabajo "Refresh local repo" funcionando - se clona con éxito, y si voy al área de trabajo, veo que tiene el compromiso HEAD de origen/maestro.

El problema son los otros trabajos; estos no parecen estar recibiendo actualizaciones. Así es como tengo uno de ellos configurado:

Git 
Repository URL file:////Users/malcolmbox/.jenkins/jobs/Refresh Local repo/workspace 
Branches to build master 

En lugar de esta actualización a la última confirmación, que es varios días anclado en el pasado.

¿Cómo puedo obtener para tirar de la punta y hacer lo correcto?

Para aclarar: la .../Actualizar repo local/área de trabajo tiene cometen 6b20268389064590147d5c73d2b6aceb6ba5fe70 presentó 28/3

La acumulación dependiente, después de ejecutar una compilación (por lo que presumiblemente haciendo un clon de git/pull paso) está desprotegido a 79a25992cc192376522bcb634ee0f7eb3033fc7e enviado 26/3 - por lo que es un par de días atrás.

Respuesta

28

Si abre la configuración del trabajo y hace clic en el botón Avanzado de la configuración de SCM de git, verá un lugar para especificar "Ruta del repositorio de referencia para usar durante la clonación (opcional)".

Si tiene un clon local de su repositorio, agregue la ruta al campo repo de referencia.

Git utilizará el clon local y compartirá la mayoría de los objetos git en el disco y extrae de github solo lo que falta del clon local, lo que da como resultado clones rápidos y espacio en disco guardado.

¿O es así exactamente como ha configurado su trabajo y no está recogiendo las últimas confirmaciones? Si es así, proporcione más detalles. Considere publicar su configuración de trabajo.

+0

Gracias - ¡esto parece exactamente lo que estoy buscando! Voy a probar ... –

+8

Solo quería aclarar: Parece que el último complemento de git ahora tiene un menú emergente de opciones avanzadas y el repositorio de referencia se encuentra en "Comportamiento de clonación avanzado". – sti

+0

¡Esto es excelente! Parece que funciona bien. – AlexeiOst

2

Eche un vistazo a Clone Workspace plugin. Puede usar eso o configurar un trabajo para actualizar un repositorio local desde Github y luego hacer que todos los demás trabajos saquen de ese repositorio local.

Esto no ayudará con el problema de que los espacios de trabajo aún necesitan el espacio de disco, pero hasta donde sé, no hay una solución simple para eso. Podría hacer que los pasos de compilación cambien a un directorio compartido fuera del área de trabajo, pero eso es raro y podría romper otras cosas. Alternativamente, puede usar un sistema de archivos que proporcione deduplicación.

+0

Estoy menos preocupado por el espacio de disco, y de todos modos creo que git es inteligente y usa enlaces cuando es posible al clonar un repositorio local. Obtener todos los otros trabajos para sacar del repositorio local es lo que quiero hacer, pero no puedo entender cómo. Parece que no obtienen nuevos compromisos incluso a través del repositorio local. –

+0

¿Cómo desencadenas las compilaciones? ¿Has intentado sondear el repositorio local y verificar el registro de sondeo? –

+0

Uso el disparador "Construir después" en las compilaciones secundarias –

0

Tuve la misma experiencia.

Tengo un trabajo para retirar el repositorio remoto real, que es github.

Cada uno de los otros puestos de trabajo (hay muchos) tiene una "URL del repositorio" de esta manera:

file:///C:/Program Files (x86)/Jenkins/jobs/webtest-local-repo/workspace/.git 

Se clona bien, pero las recuperaciones posteriores no se nota ningún cambio.

El mismo problema se presenta en gitbash, así que supongo que esto es un problema de git, no un problema de jenkins.

Mi horrible solución fue hacer que las tareas dependientes borren sus espacios de trabajo cuando terminen de compilarse, de modo que cada operación de git es un "clon". Es ridículo, pero tal vez menos ridículo que tener un trillón de empleos en el mismo github repo.

ZOMG! Eso tampoco funcionó, porque aunque git podía clonar con éxito el repositorio, jenkins recordaría la revisión anterior y construiría la misma de nuevo. Quizás esté relacionado con this issue, no sé, estoy harto. Nos dimos por vencidos, y ahora todos los trabajos sondean a github nuevamente. Tal vez voy a obtener un gancho trabajando en su lugar.

Cuestiones relacionadas