Comencé a experimentar con Hudson como servidor de compilación. Estoy usando subversion y lo tengo configurado para sondear cada minuto. El problema que estoy viendo es que si una compilación en la revisión 10 demora 5 minutos y hay 5 confirmaciones durante ese tiempo, Hudson compilará la revisión 15.¿Se puede configurar Hudson para que construya todas las revisiones?
¿Hay alguna forma de garantizar que se construya cada revisión?
Hudson todavía no tiene esta capacidad, pero ha sido solicitado algunas veces en la lista de correo. Ver issue 673
Busqué ese error. El rastreador de errores se ha movido, el problema ahora está en http://issues.hudson-ci.org/browse/HUDSON-673 y todavía no se ha resuelto. – Bluehorn
Gracias. Actualicé el enlace. –
En SCM, parte de la configuración de compilación debe tener la sección Disparadores de compilación y la opción "Desencadenar compilaciones de forma remota (p. Ej., A partir de secuencias de comandos)". De acuerdo con la información de ayuda al lado de esa opción, puede realizar un script de acción posterior a la confirmación para que cada confirmación inicie una compilación nueva. Como Hudson tiene la cola de compilación, debería tener todas las revisiones creadas.
Aquí hay un enlace que podría ayudarle a: https://hudson.dev.java.net/build.html
Aquí está el ejemplo cómo iniciar el trabajo de construcción con los parámetros (ver a mi comentario para más detalles): http://wiki.hudson-ci.org/display/HUDSON/Parameterized+Build
No estoy seguro de que funcione directamente: la primera confirmación desencadenará una compilación, luego 3 commit desencadenará 3 compilaciones adicionales antes de la 1ra. Desafortunadamente, la segunda compilación en la cola hará una actualización y compilará la última versión, al igual que las siguientes compilaciones. Lo que se necesita para poder pasar un número de revisión a la solicitud de compilación y tener ese número utilizado durante la actualización. –
Tienes razón, no he pensado en ese escenario obvio. Pero como he visto en la documentación de Hudson, es posible invocar el trabajo de compilación con parámetros para que pueda definir el parámetro de cadena de construcción RevisionToBuild y establecerlo desde el script de esa manera: "http: // server/job/myjob/buildWithParameters? RevisionToBuild = 1234 "y, por supuesto, modificar correctamente la ruta del repositorio svn para usar ese parámetro. – grapkulec
Pero puede hacer que la cola de creación tenga un solo trabajo (para un ejecutor de compilación determinado establezca el "n. ° de ejecutores") y obtendrá el resultado que busca ... incluso si las compilaciones paralelas fueran más rápidas. – MattyT
Tienes que hacer algunas cosas para construir exactamente cada revisión:
REVISION cadena a su trabajo${REVISION} a la URL del repositorio, https://server/path/myproject${REVISION}REVISION solo se expande en la URL, pero al crear la carpeta, Hudson no la expandirá, resu lting en una carpeta denominada: myproject${REVISION} /usr/bin/wget \ --auth-no-challenge \ --no-check-certificate \ --user=me \ --password=mypasswd \ https: //server/path/job/jobname/buildWithParameters?delay=0sec\&REVISION=%40$REV \ -O /dev/null Si desea desencadenar una acumulación manualmente, tiene dos posibilidades:
@ El signo es muy importante porque todo este truco se basa en el hecho de que la subversión complemento interpreta como [email protected]get revision NNN from repository at URL. Si olvida el @, Subversion simplemente dirá que no puede encontrar la carpeta https://server/path/myprojectNNN. También es por eso que debe ingresar %40 entre REVISION= y $REV en el comando wget, %40 es el carácter escapado para @.
La clave para asegurarse de que cada confirmación se construye en Hudson es "Construir parametrizado" y sólo si gatillo construir con diferentes valores de los parámetros, Hudson pensar que es de nueva construcción y se llevará a cabo en cola de construcción.O que no se grabará por Hudson, ya que consideran que es la acumulación de sentido en comparación con anterior
por ejemplo, puede hacer clic en "Crear ahora" para activar la compilación tres veces y simplemente dejar la compilación para como "nula". verá que solo las primeras dos compilaciones se encuentran en la cola de Hudson. El tercero será ignorado: P genial, pero es realmente malo que no se encuentre en algún documento, pero con mis experimentos para los tiempos :(
Tomé el enfoque de fchateaus (¡gracias hombre!) Y lo modifiqué para que funcione con Mercurial.
Deberá editar .hg/hgrc en el servidor central y colocar un enlace de grupo de cambios. Tenga en cuenta que changegroups solo establece el primer conjunto de cambios en la variable de entorno HG_NODE, por lo que debe hacer una sugerencia de hg para tomar el nodo de punta real y pasarlo a través de URL en su lugar. Un truco para hacer en una línea, pero lo descubrí.
Esto es lo que harías por Hudson corriendo en Windows.
[hooks]
# this uses wget to hit the hudson url responsible for starting a build - %HG_NODE% only gets first changeset of changegroup, so use hg tip to grab changeset most recently added instead
changegroup.hudson = for /f "tokens=*" %G IN ('hg tip --template {node}') DO "C:\Program Files (x86)\UnxUtils\usr\local\wbin\wget" --non-verbose --spider http://HudsonServer:8080/job/{Repository}/buildWithParameters?HgRevId=%G | ECHO Result of Hudson Polling Request For Node %G
# TODO: when Hudson implements polling with parameters, change to something like this
#changegroup.hudson = for /f "tokens=*" %G IN ('hg tip --template {node}') DO "C:\Program Files (x86)\UnxUtils\usr\local\wbin\wget" --non-verbose --spider http://HudsonServer:8080/job/{Repository}/polling?HgRevId=%G | ECHO Result of Hudson Polling Request For Node %G
Debe tener cuidado de que esto no cause problemas de rendimiento para Hudson. Por ejemplo, si realiza commits cada pocos segundos, mientras que una compilación hudson tarda unos minutos. Pronto inundarás la cola de compilación. – toolkit
Por mi vida, no veo por qué podría ser necesario. ¿Por qué sería importante algo diferente al estado actual de la base del código? – sal
Hola sal, la razón de esto es la prueba. Nuestro objetivo es poner cada revisión a través de una prueba de regresión. Entonces, si no estamos construyendo cada revisión, no estamos probando cada revisión. Esto causa problemas si rev n funciona, pero rev n + 10 no lo está y no hemos probado ninguna de las revisiones entre. ¿Qué cambio causó la regresión? – CodeBuddy