2009-11-21 10 views
6

El plugin git para hudson funciona bien. Sin embargo, la secuencia de comandos de compilación debe actualizar un número de versión en los archivos en el repositorio, confirmar y volver al repositorio.Hudson infinite loop polling para cambios en el repositorio de Git?

Cuando Hudson sondea al lado para comprobar si hay cambios, entra en un bucle infinito porque ve que se compromete como un "cambio" se vuelve a crear, lo que confirma un cambio, se vuelve a generar, se comete otro cambio, etc. .. Tienes la idea.

lo paré, se pasó una "git log" en cada repositorio y compararon los últimos cometer los identificadores son exactamente los CABEZA misma usando git ls-árbol

Además, Hudson se ejecuta este comando para comprobar si hay cambios:

git fetch + refs/heads/: refs/mandos a distancia/origen/ cABEZA git ls-árbol

desde propio Hudson empujó el commit desde su repositorio espacio de trabajo, y al parecer los resultados coinciden ls de árboles, ¿cómo se puede este comando determina que haya habido un cambio?

Parece que debe almacenar los resultados de ls-tree antes de realizar la compilación y compararlos con los que no tendrán la última confirmación. Ah. Puedo intentar desactivar el compromiso para probar esa teoría.

De todos modos, en lugar de solucionar cualquier problema en el complemento git para Hudson, ¿qué puedo hacer para asegurarme de que al final de mi compilación los repos son idénticos y que Hudson lo verá así?

¿Cómo solucionar esto? ¿Algunas ideas?

Wayne

+0

Efectivamente. Cuando la confirmación está comentada para que la secuencia de comandos solo empuje a algunos repositorios, funciona correctamente. Es decir, Hudson reconoce que se produjeron cambios cero y espera cambios sin bucle. Entonces, ¿cómo detener el ciclo infinito? Parece que el complemento git para Hudson guarda el estado de repos después de la recuperación inicial de la compilación. Pero parece que debería guardar nuevamente el estado de repos después de una compilación exitosa en caso de que la compilación se haya comprometido, o al menos dar eso como una opción. ¿Alguien tiene una idea más fácil y más rápida para resolver esto? – Wayne

+0

Oh, encontré un tenedor del plugin git-hudson en github donde parece que alguien más ya ha agregado el manejo de esta situación. Estoy descargando y construyendo e intentaré eso. De nuevo, si alguien tiene una mejor solución, por favor asesórese. Voy a publicar de nuevo si eso lo resuelve. – Wayne

Respuesta

3

Y la respuesta es! ...

El plug-in Git Hudson ya estaba en horquilla por alguien para añadir esta característica funciona bien. Aún así, tuve que sacar la fuente y solucionar un par de problemas menores.

Ahora funciona muy bien. La compilación se compromete, y el complemento de Git vuelve al repositorio sin bucles, pensando que ha cambiado nuevamente.

¡Maravilloso!

Si alguien más necesita este look para la horquilla tickzoom del Hudson-GIT-Plugin en Github.com, pero compruebe si ya se ha integrado de nuevo en el proyecto principal. El comentarista dijo que estaba interesado y planea combinar las horquillas.

Wayne

+0

Oh. esto es genial! Resulta que el complemento Hudson Git ya maneja esta situación. Lo describe en la documentación y estuvo por encima de mi cabeza hace unos días. La idea es solo comprometerse con las ramas de "características". Luego, el servidor de compilación fusiona primero la rama de características con una rama de integración y luego realiza su trabajo. De esta forma, nunca es necesario que el servidor automático tenga fusiones de avance no rápidas y las confirmaciones sucedan en la bifurcación integrada en el orden correcto. Increíble. Tienes que amar el poder de Git. – Wayne

5

Su sistema de construcción no debe tener ninguna interacción de escritura con el sistema de control de versiones. Ciertamente no debería empujar esos cambios automáticamente.

Su sistema de compilación puede preguntar git (a través de git describe, por ejemplo) cuál es la revisión actual. Cualquier otra cosa es redundante y propensa a errores.

Otra cosa que puede considerar no es la búsqueda de cambios. Parece una manera tonta de operar. (Es cierto que soy un usuario de buildbot pesado bastante acostumbrado a que todo se active en eventos).

El git repo que se está sondeando sabe cuándo cambia. Simplemente debería decirle al sistema de CI que inicie una compilación de inmediato en función de eso. Obtienes tus compilaciones más rápido y, como todas están activadas, no tienes las computadoras ocupadas haciendo mucho trabajo sin una buena razón.

+0

Desafortunadamente, la escritura debe ocurrir porque la construcción debe etiquetar la revisión con un número de versión como 0.5.6.135 y también actualizar los archivos fuente con el número para que los binarios compilados tengan la revisión. Eso permite seguir los errores al código fuente correcto. Anteriormente usábamos SVN y ese complemento tenía la opción de "ignorar" ciertos archivos cuando se buscaban cambios. Así que lo hicimos ignorar nuestros archivos de versión. Git es diferente, por supuesto. Si conoce alguna otra forma de lograr lo mismo, hágamelo saber por favor. – Wayne

+0

Me gusta su idea de no buscar realmente cambios. El obstáculo allí también está evitando el bucle infinito del empuje de la construcción automática. Entonces, este método también debe tener una forma de compararlo también. Eso es complejo. Entonces, las encuestas y las comparaciones parecen más directas. Y sondear cada 1 minuto para realizar cambios definitivamente no es ningún tipo de trabajo para que una computadora se preocupe por hacerlo. – Wayne

+0

Para tu información, ahora me doy cuenta por qué dices que la compilación nunca debe escribirse en el repositorio. Lo tengo todo configurado y funcionando, pero el equipo de construcción de CI escribe y crea confirmaciones de palabras no rápidas cuando lo hace al final de la compilación mientras los codificadores continúan codificando y confirmando durante la compilación. Requisitos complejos pero necesarios. Voy a publicar otra pregunta para abordar esto. – Wayne

Cuestiones relacionadas