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

0
24217

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

 

Alejandro es socio fundador de Autentia y nuestro experto en Java EE, Linux y optimización de aplicaciones empresariales. Ingeniero en Informática y Certified ScrumMaster. Seguir @alejandropgarci Si te gusta lo que ves, puedes contratarle para darte ayuda con soporte experto, impartir cursos presenciales en tu empresa o para que realicemos tus proyectos como factoría (Madrid). Puedes encontrarme en Autentia: Ofrecemos servicios de soporte a desarrollo, factoría y formación.

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad