Tutorial desarrollado por

Alejandro Pérez García

Alejandro es socio fundador de Autentia y nuestro experto en J2EE, Linux y optimización de aplicaciones empresariales.

Ingeniero en Informática y Certified ScrumMaster

Si te gusta lo que ves, puedes contratarle para impartir cursos presenciales en tu empresa o para ayudarte en proyectos (Madrid). Puedes encontrarme en Autentia

 

Catálogo de servicios de Autentia

Descargar (6,2 MB)

Descargar en versión comic (17 MB)

AdictosAlTrabajo.com es el Web de difusión de conocimiento de Autentia.

Catálogo de cursos

Descargar este documento en formato PDF: hudsonSubversionPush.pdf

Cómo conseguir que Subversion avise a Hudson para lanzar una build

Creación: 27-10-2009

Índice de contenidos

1. Introducción
2. Entorno
3. Activando una build de forma remota
4. Probando a lanzar una build de forma remota
5. Haciendo que Subversion lance la build cuando se haga un commit
6. Conclusiones
7. Sobre el autor

1. Introducción

En el tutorial http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=hudsonInstalacionTomcat vimos como instalar y dar nuestros primeros pasos con Hudson. Vimos como podíamos configurar Hudson para que cada x tiempo revise el repositorio a ver si ha habido cambios, y en tal caso lanzar la build.

En este tutorial vamos a ver como configurar Subversion para que sea este el que avise a Hudson cada vez que hay un commit, y así se lance la build. Es decir, ya no será Hudson el que continuamente este chequeando el Subversion, ahora Hudson será pasivo, y será Subversion el que le de "un toque" cada vez que se hace un commit en el proyecto.

Con esto conseguimos dos ventajas:

• Hudson no pierde tiempo y ni consume recursos preguntando al repositorio si ha habido cambios.

• Cada vez que se haga un commit obtenemos, de forma inmediata, una compilación completa con Hudson, en vez de tener que esperar a que Hudson haga el chequeo.

Por esto, este método de lanzar la build sería más recomendable que el que vimos en el tutorial anterior (esto aplica especialmente si en vez de Subversion usamos CVS, ya que en CVS ver si ha habido cambios es una operación costosa).

2. Entorno

El tutorial está escrito usando el siguiente entorno:

• Hardware: Portátil MacBook Pro 17' (2.93 GHz Intel Core 2 Duo, 4GB DDR3 SDRAM, 128GB Solid State Drive).

• NVIDIA GeForce 9400M + 9600M GT with 512MB

• Sistema Operativo: Mac OS X Snow Leopard 10.6.1

• JDK 1.6.0_14

• Maven 2.2.1

• Hudson 1.330

• Subversion 1.6.3

3. Activando una build de forma remota

Hudson está realmente bien pensado, ya que, además de la interfaz de usuario, viene preparado con varias API para poder integrar Hudson con otros procesos, scripts, aplicaciones, …

Una de estas API consiste simplemente en hacer un GET a una url determinada, para así activar la build.

Para que esto sea posible lo primero que tenemos que hacer es cambiar la configuración para activar esta característica. Así que entramos en Hudson, seleccionamos el trabajo pinchando sobre le nombre del mismo en la lista de la pantalla principal (el "Dashboard"). Una vez en la pantalla del trabajo pinchamos sobre "Configure" y accedemos a la pantalla de opciones del proyecto (la misma que vimos en el tutorial anterior para la creación del trabajo).

En la sección "Build Triggers" desmarcamos la opción "Poll SCM" (la habíamos seleccionado en el tutorial anterior) y marcamos la opción "Trigger builds remotely (e.g., from scripts)". Al marcar esta opción vemos como aparece el cuadro de texto "Authentication Token". Aquí pondremos el nombre del token de autenticación.

Este token simplemente es una palabra que, cuando hagamos la invocación remota, habrá que indicar. Es un pequeño medio de seguridad, de forma que si alguien no sabe la palabra, no podrá hacer la invocación. En nuestro caso no es demasiado importante ya que tenemos activada la autenticación, así que para poder hacer la invocación habrá que tener un usuario y una clave, y Hudson dejará registrado quien hizo la invocación.

Con todo esto las opciones deberían quedar más o menos así (recordad que el token de autenticación puede ser cualquier palabra de vuestra elección).

Conviene destacar como debajo del campo de texto donde hemos puesto el token, Hudson nos está dando una pequeña ayuda de como tendremos que hacer la invocación remota.

Por supuesto le damos al botón "Save" para guardar los cambios.

4. Probando a lanzar una build de forma remota

Aquí simplemente vamos a probar que la configuración anterior es correcta y que tenemos claro el comando que tenemos que lanzar para activar al build.

El comando sería:

$ wget --auth-no-challenge --no-check-certificate --http-user=alex --http-password=**** https://localhost:8080/hudson/job/autentia%20wuija/build?token=TOKEN

--auth-no-challenge lo uso tal como recomienda la documentación oficial de Hudson por tener la versión 1.11 del comando wget (http://wiki.hudson-ci.org/display/HUDSON/Authenticating+scripted+clients).

--no-check-certificate lo uso porque estamos accediendo por https y estoy usando un certificado autofirmado, que el cliente wget no va a reconocer como seguro (pero yo si ;)

--http-user y --http-password nos permiten indicar el usuario y la clave para conectarnos a Hudson.

Y finalmente la URL. Podéis ver como hemos puesto lo que nos indicaba en la configuración y como hemos puesto como token la palabra que habíamos elegido (en este caso "TOKEN").

Si lanzamos este comando desde una consola y después nos vamos a Hudson deberíamos ver como se está haciendo una build.

5. Haciendo que Subversion lance la build cuando se haga un commit

En el Subversion (y prácticamente en cualquier sistema de control de versiones) se lanzan eventos con cada operación. De esta forma podemos hacer scripts que se ejecuten con estos eventos. A estos scripts se les suele llamar "hooks" (garfios, Como el "Captain Hook" de Peter Pan http://www.youtube.com/watch?v=suaBxCJZe-k).

Lo que vamos a hacer es un hook que, después de un commit ejecute el comando que hemos visto antes para lanzar la build. Vamos ha hacerlo un poco más elaborado, de forma que si tenemos en un repositorio de Subversion más de un proyecto, sólo se lance la build si hemos hecho cambios dentro del proyecto deseado.

En la máquina donde tenemos el Subversion instalado (es un Linux), crearemos el script /var/lib/svn/hudson-launch-build.sh, con el siguiente contenido. Este script lo reutilizaremos desde todos los repositorios que queramos:

#!/bin/bash
# Este script comprueba si se han hecho cambios en un directorio concreto,
# y en tal caso lanza una build en Hudson

REPOS="$1"
REV="$2"
PROJECT_NAME="$3"
HUDSON_JOB="$4"

HUDSON_USER=alex
HUDSON_PASSWORD=****
HUDSON_HOST=localhost:8080

IS_PROJECT_CHANGED=`svnlook dirs-changed $REPOS --revision $REV | fgrep $PROJECT_NAME`

if [[ -n $IS_PROJECT_CHANGED ]]; then
    wget --quiet --auth-no-challenge --no-check-certificate --http-user=$HUDSON_USER --http-password=$HUDSON_PASSWORD https://$HUDSON_HOST/hudson/job/$HUDSON_JOB/build?token=TOKEN
    exit 0
fi

Vemos como en el script comprobamos con svnlook si se hicieron cambios dentro del proyecto (directorio) que hemos indicado en $3. En caso de haber cambios se ejecuta el comando wget para que Hudson lance la build. Después del wget hacemos un exit 0, esto es porque el wget, aunque va a funcionar correctamente, va a terminar con un código 1 y el Subversion se va creer que el hook no funcionó correctamente.

Ahora creamos el hook que invocará a este script. Los hooks se crean dentro de cada repositorio, así que haremo:

cd /var/lib/svn/autentia/hooks
cp post-commit.tmpl post-commit

Editamos el fichero post-commit, de forma que su contenido sea el siguiente:

REPOS="$1"
REV="$2"
/var/lib/svn/hudson-launch-build.sh $REPOS $REV autentia-wuija-parent autentia%20wuija

Vemos como llamamos al script anterior, pasándole el directorio del repositorio, el número de revisión, el nombre del proyecto (directorio que se buscará con svnlook) y el nombre del job de Hudson para poder lanzar la compilación.

Ojo!!! es muy importante que tanto el script hudson-launch-build.sh como post-commit, tengan permiso de ejecución.

6. Conclusiones

En esta ocasión hemos tenido que meternos un poco más en las tripas, pero como se ha visto, tampoco es tan complicado, y las ventajas merecen la pena.

Esta forma de activar las builds ahorra recursos y nos ayuda a detectar los posibles problemas lo antes posible. Así que el esfuerzo merece la pena con creces (y después de este tutorial, el esfuerzo se queda en nada ;)

7. Sobre el autor

Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software) y Certified ScrumMaster

Socio fundador de Autentia (Formación, Consultoría, Desarrollo de sistemas transaccionales)

mailto:alejandropg@autentia.com

Autentia Real Business Solutions S.L. - "Soporte a Desarrollo"

http://www.autentia.com

Tutoriales recomendados

Nombre	Resumen	Fecha	Visitas	Valoración	Votos	Pdf
Primeros pasos con Enterprise Architect y UML 2.x	Introducción básica a la herramienta EnterpriseArchitec mediante el uso de diagramas UML 2	2010-02-04	261	-	-
JMeter. Uso de funciones.	En este tutorial tratamos el uso de las funciones más habituales de la herramienta JMeter.	2010-01-26	462	-	-
Autenticando los usuarios de Sonar contra un LDAP	En este tutorial vamos a ver cómo podemos hacer que la autenticación de Sonar sea a través de un LDAP.	2010-01-18	441	-	-
JMeter. Gestión de usuarios	En este tutorial tratamos la simulación de distintos usuarios, en la herramienta JMeter, mediante el archivo externo users.xml o mediante la función Counter.	2010-01-14	696	-	-
JMeter y JSF. Extracción del parámetro ViewState	En este tutorial ofrecemos una solución a la parametrización del atributo ViewState, de JSF (Java Server Faces), cuando ejecutamos scripts de pruebas de carga mediante la herramienta JMeter.	2010-01-11	661	-	-
Monitor de Hudson para Eclipse.	En este tutorial vamos a ver un plugin para Eclipse que nos permitirá consultar y realizar algunas opciones interesantes sobre los proyectos que tenemos configurados en Hudson.	2010-01-07	699	-	-
Pruebas funcionales de servicios web con soapUI	Las pruebas unitarias en cualquier paradigma de programación son, más que una buena práctica, una garantía para obtener un software robusto y (más) fácilmente mantenible. Como responsables de diseño o desarrollo de web services hemos de aplicar estas buen	2009-12-28	1117	-	-
JavaBean Datasource Ireport	La particularidad del caso que nos ocupa, es conseguir que la fuente de datos del informe sea una lista de JavaBeans y no una consulta definida previamente en el informe.	2009-12-14	1257	Bueno	1
Integrando Sonar con Hudson	En este tutorial vamos a ver como a partir de un build satisfactorio de Hudson se puede analizar automáticamente el código Java mostrando el resultado en la herramienta Sonar.	2009-12-09	786	-	-
Analizando la calidad del código Java con Sonar	En este tutorial vamos a dar a conocer la herramienta Sonar para el control de la calidad del código de nuestros proyectos	2009-12-07	1591	-	-