16

Se necesita una herramienta git que cumpla con las especificaciones a continuación. ¿Ya existe uno? Si no, crearé un script y lo pondré disponible en GitHub para que otros lo usen o contribuyan. ¿Hay una manera completamente diferente y mejor de resolver la necesidad de construir/probar cada compromiso en una sucursal en un repositorio git? No solo a lo último sino a cada uno de regreso a un cierto punto de partida.¿Alguna herramienta para hacer que git construya cada compromiso en una sucursal en un repositorio separado?

Antecedentes: nuestro entorno de desarrollo utiliza un servidor de integración continua separado que es maravilloso. Sin embargo, todavía es necesario realizar compilaciones completas localmente en la PC de cada desarrollador para asegurarse de que la confirmación no "rompa la compilación" cuando se envía al servidor de CI. Desafortunadamente, con las pruebas de unidades automáticas, esas construcciones obligan al desarrollador a esperar 10 o 15 minutos para una construcción cada vez.

Para resolver esto, hemos configurado un repositorio git "espejo" en cada PC desarrolladora. Así que nos desarrollamos en el repositorio principal, pero cada vez que se necesita una compilación completa local. Ejecutamos un par de comandos en el repositorio espejo para recuperar, verificar el compromiso que queremos y compilar. Sus trabajos son extremadamente encantadores, así que podemos seguir trabajando en el principal con la construcción en paralelo.

Ahora solo hay una preocupación principal. Queremos asegurarnos de que cada commit solo construya y pase las pruebas. Pero a menudo nos ocupamos y olvidamos construir varios commits nuevos. Luego, si la construcción falla, debe hacer una bisección o calcular manualmente cada compromiso interino para descubrir cuál se rompió.

Los requisitos para esta herramienta:

  1. La herramienta buscará en otro repo, origen por defecto, ir a buscar y comparar todos los envíos que se encuentran en las ramas a 2 listas de confirmaciones. Una lista debe contener confirmaciones compiladas con éxito y las otras listas comprometen que fallaron.

  2. Identifica las confirmaciones que aún no están en ninguna de las listas y comienza a compilarlas en un bucle en el orden en que se cometieron. Se detiene en el primero que falla.

  3. La herramienta agrega apropiadamente cada confirmación a la lista de resultados correctos o fallidos después de intentar crear cada una de ellas.

  4. La herramienta ignorará las confirmaciones "heredadas" que son anteriores a la confirmación más antigua en la lista de éxito. Esta lógica hace posible el punto de partida en el siguiente punto.

  5. Punto de partida. La herramienta crea un compromiso específico para que, si tiene éxito, se agregue a la lista de éxitos. Si se trata de la confirmación más temprana en la lista de éxitos, se convierte en el "punto de partida" para que ninguna de las confirmaciones anteriores se examine en busca de compilaciones.

  6. ¿Solo soporte de árbol lineal? Al igual que bisect, esta herramienta funciona mejor en un árbol de compromiso que, al menos desde su punto de partida, es lineal y sin fusiones. Es decir, debería ser un árbol que se creó y actualizó completamente a través de rebase y commits rápidos.

  7. Si falla en una confirmación en una bifurcación se detendrá sin construir el resto que siguió a esa. En cambio, si se moverá a otra rama, si hay alguna.

  8. La herramienta debe realizar estos pasos una vez de forma predeterminada, pero permite que un parámetro se repita con una opción para establecer cuántos segundos hay entre bucles. Otras herramientas como Hudson o CruiseControl podrían hacer más opciones de programación de lujo.

La herramienta debe tener buenos valores predeterminados pero permite un control opcional.

  1. ¿Qué repos? origen por defecto.

  2. ¿Qué ramas? todos por defecto.

  3. ¿Qué herramienta? de forma predeterminada, un archivo ejecutable para ser proporcionado por el usuario llamado "buildtest", "buildtest.sh" "buildtest.cmd" o buildtest.exe "en la carpeta raíz del repositorio.

  4. ¿Demora de bucle? ejecutar una vez por defecto con opción de bucle después de un número de segundos entre iteraciones.

Respuesta

13

escribí una herramienta que se llama git test-sequence hace un tiempo para hacer exactamente esto.

Sólo estaba pensando en los blogs de ello porque un amigo me decía que le había ahorrado un montón de trabajo esta semana.

+0

Interesante, esta herramienta muy elegante. Y construye iterativamente todas las confirmaciones en una rama. ¿Cómo se "recuerda" la próxima vez que la comete ya intentada, exitosa o fallida? Si las compilaciones solo demoran unos segundos, la fuerza bruta está bien. Pero mis compilaciones toman de 10 a 15 minutos. ¿Entonces tal vez clonar su repositorio y agregar un "recuerdo" y luego ofrecerle que actualice su sucursal funcionará? – Wayne

+0

¿Usted o alguien tiene una sugerencia sobre dónde "almacenar" la memoria? En mi caso, este es un repositorio espejo utilizado solo para compilaciones, por lo que agregar los dos archivos a .ignore estará bien. ¿Pero hay una forma más estándar de almacenar ese tipo de memoria como bisección en las herramientas? Tal vez la carpeta bajo .git? – Wayne

+0

Es más fácil simplemente darle un rango. Digamos que tiene una rama de puntero llamada 'known_good' que sube cada vez que una compilación tiene éxito. Luego ejecutaste 'git test_sequence known_good..master 'do_build.sh && git update-ref HEAD refs/heads/known_good' – Dustin

Cuestiones relacionadas