Nov 11 2009

Hudson, Sventon y conexiones SSH con llaves (bajo Tomcat y Windows)

Categoría: Integración ContinuaJuan @ 1:59 pm

¡Demonios!, esto debe ser una tontería y seguramente que soy el único pardillo que no sabía como configurar Hudson y Sventon juntos (un navegador de repositorios para el que no lo conozca) bajo Tomcat y en Windows para que funcionen usando svn+ssh con llaves. Si no es así, y ya que me ha costado sangre, sudor y lágrimas, ahí os dejo la solución (que aunque simple, me ha costado mucho encontrar).

Basta con añadir los siguientes parámetros al final del archivo catalina.properties que normalmente se encuentra en C:\Program Files\Apache Software Foundation\Tomcat 6.0\conf:

svnkit.ssh2.key=_llave_
(por ejemplo: “D:/ssh_keys/userkeys/llave”)
svnkit.ssh2.username=_nombre_de_usuario_

Seguro que esta ni es la mejor solución, ni la más elegante pero al menos funciona (que con el tiempo que me ha llevado es, al menos por ahora, más que suficiente).

Si alguien conoce una manera mejor o más apropiada, le estaría muy agradecido si la compartiese.

Etiquetas: , , , ,


Feb 05 2009

Integración Contínua con Hudson, Ant, Svn y NetBeans

Categoría: Integración ContinuaJuan @ 7:59 pm

El post que siempre he querido escribir sobre integración contínua y Hudson y nunca he tenido tiempo lo ha escrito excelentemente Iván en su blog Bits y Bytes.

La entrada explica como montar un entorno de integración contínua desde cero usando Hudson, Ant, SVN y NetBeans. Para ser exactos yo lo quería haber escrito usando algo en C++ o Python pero para el caso es “casi lo mismo”. Como artículo introductorio me parece excelente y las sutilizas de C++ o Python ya las intentaré escribir poco a poco.

Enhorabuena, Iván, por tu gran anotación. ¡Gracias!

Etiquetas: , , ,


Ene 26 2009

Hudson (en Windows y como servicio) y CVS

Categoría: Integración ContinuaJuan @ 12:51 pm

Cómo es el sistema, lo primero: un Windows con CVSNT para acceder al repositorio y Hudson en Tomcat configurado como un servicio.

El problema viene cuando Hudson intenta acceder al repositorio por primera vez y la huella del repositorio no está en la caché. Como Hudson lo ejecuta no interactivamente no podemos escribir “yes” y darle al intro al ver el siguiente mensaje:

The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is. The server's key fingerprint is:
ssh-dss 1024 4f:8...
If you trust this host, hit Yes to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, hit No.
If you do not trust this host, hit Cancel to abandon the
connection.SCM check out aborted

Bueno, no hay problema, podemos hacerlo desde la consola y añadir la huella a la cache manualmente… Pues no, ahora el problema es que Hudson es un servicio y ejecuta bajo la cuanta de usuario Local Service Account y yo, personalmente, no sé como puedo entrar al sistema con ese usuario (lo siento, no tengo tanta experiencia con Windows) Supongo (quizá erróneamente) que esta cuenta no se puede usar para entrar al sistema ya que es una cuenta especial y hacerlo con otro usuario no arreglaría nada ya que la caché es dependiente del usuario.

El siguiente paso es añadir la huella manualmente a la caché (un fichero) ya que sé que se puede hacer en Linux. Mal otra vez, Windows no tiene esta caché como un fichero sino que utiliza el registro. Buscando en el registro encontré una entrada para mi usuario (ya que previamente había accedido al repositorio y añadido la huella a la caché) donde estaba la huella guardada y la copié a HKEY_USERS para que cualquier usuario pueda acceder a ella. La entrada es algo así:

Key Name: HKEY_USERS\.DEFAULT\Software\SimonTatham\PuTTY\SshHostKeys
Class Name: NO CLASS
Last Write Time: 23.01.2009 - 18:35
Value 0
Name: dss@22:bla_bla.com
Type: REG_SZ
Data: 0xb477b...

Desde la línea de comandos, se puede añadir la huella fácilmente como sigue:

reg add HKEY_USERS\.DEFAULT\Software\SimonTatham\PuTTY\SshHostKeys /v dss@22:bla_bla.com /d 0xb477b...

Ahora Hudson, ejecutado como un servicio, accede felizmente y sin problemas al repositorio donde está el código.

Etiquetas: , ,


Nov 26 2008

Configurar un proyecto con pruebas muy lentas en Hudson

Categoría: Integración ContinuaJuan @ 12:09 pm

Véamos es siguiente escenario: un proyecto en el que la construcción del ejecutable, por ejemplo, y sus test unitarios son muy rápidos (1 minuto por decir algo) mientras que sus pruebas de más alto nivel son mucho más lentas (unos 10 minutos, por ejemplo).

En este caso, lo que nos gustaría es que mientras los tests lentos están siendo ejecutados, la construcción y la ejecución de los test unitarios se haga continuamente y, una vez acabados los tests lentos, que estos se vuelvan a ejecutar sólo para la última versión estable de la construcción y los test unitarios (y no para todas las que ha habido entre medias) ¿Claro?, espero que sí.

Este caso que parece simple no lo es tanto en Hudson y hay que dar un pequeño rodeo. Usar tres trabajos en lugar de dos, ahora os explico el porqué.

Si configuramos 2 trabajos, uno dependiente del otro, siempre que el primero acabe, el segundo se lanzará. Si el segundo ya está en ejecución, se pondrá en una cola de espera con lo que tendremos un segundo trabajo por cada uno de los primero (cosa que no queremos). Si utilizamos un plug-in llamado “locks and latches” y configuramos un cerrojo, entonces hasta que no acabe el segundo no podremos lanzar de nuevo el primero (cosa que tampoco queremos).

Para configurar nuestro escenario necesitamos 3 trabajos. Un nuevo trabajo intermedio (M) que será ejecutado por el primer trabajo rápido (R) y que lanzará el segundo trabajo lento (L), es decir, R -> M -> L. Además también necesitamos el plug-in del que hablamos anteriormente, “locks and latches“.

El trabajo A se configura un cerrojo (L1), en el trabajo M dos (L1 y L2), y en el trabajo L uno, (L2). El trabajo A comparte el cerrojo con M pero no con B y el trabajo B comparte el suyo con M pero no con A. De esta manera, podremos ejecutar el trabajo A varias veces mientras que B esta en ejecución. Cuando B acabe se volverá a lanzar cuando acabe A con la última versión del código.

Ahora que lo pienso, es posible que también funcione usando un único lock en M y B pero no lo he probado. Hace tiempo que utilicé esto y ya no lo tengo configurado así que dejo la prueba de si la “optimización” funciona o no para vosotros. Por favor, hacédmelo saber.

Etiquetas:


Nov 13 2008

Integrar los resultados de gTest en Hudson

Categoría: Integración Continua, Test UnitariosJuan @ 10:53 am

gTest puede escribir un informe sobre los tests que ha ejecutado en un fichero XML, sin embargo, este fichero no es correctamente interpretado por Hudson y, por tanto, no podemos ver cuales han sido los resultados (número de tests ejecutados, errores si los hay, etc.) ni tampoco las gráficas.

Una manera fácil y rápida de solucionar esto es transformando el fichero XML con un fichero XSL usando Ant. De esta manera, el fichero que contiene los resultados en XML es transformado en otro que Hudson puede entender mediante el uso de la opción jUnit.

Los pasos a seguir son los siguientes:

  1. Configurar Ant en Hudson (”Manage Hudson” -> “Configure System”)

    Configuración de Ant en Hudson

  2. Guardar la nueva configuración.
  3. Añadir los ficheros adjuntos build.xml y unittest.xsl al directorio raíz del proyecto en el repositorio (que espero uséis)
  4. Añadir un paso en el proceso de construcción (”Invoke Ant”) del trabajo donde estemos usando gTest (”Job Configuration” -> “Add Build Step” -> “Invoke Ant”)

    Invocar Ant al construir un trabajo

  5. Habilitar la opción “Publish JUnit test result report” en la misma ventana de configuración del trabajo.

    Publicar informe de jUnit en Hudson

  6. Guardar la nueva configuración.

Esto debería ser todo. Después de construir el trabajo una vez más deberiáis ver la gráfica actualiza y poder ver los tests uno por uno y los errores si los hay.

Etiquetas: ,


Ago 19 2008

Interacción con el escritorio, JSUnit y Hudson

Categoría: Integración ContinuaJuan @ 10:35 am

Hace unas cuantas semanas trabajando con un equipo en Kuala Lumpur me encontré con un problema al utilizar JSUnit junto con Hudson (en Windows). Para quien no lo conozca, Hudson, es un motor de integración continua similar a CruiseControl que, quizá, sea el más conocido (nota mental: escribir una entrada en exclusiva para Hudson en el futuro).

JSUnit, el entorno de test unitarios para JavaScript, utiliza un navegador (Explorer, FireFox, Opera, etc.) para ejecutar las pruebas. Cuando lanzaba las pruebas desde la consola (usando ant), estas eran ejecutadas sin problemas (abriendo el navegador pertinente y cerrándolo al terminar), sin embargo, cuando la misma operación era efectuada por Hudson, el navegador no era lanzado aunque el proceso era ejecutado (el proceso aparecía en ejecución en la lista de procesos).

Hudson normalmente es ejecutado por Apache Tomcat, el cual suele ser un servicio, y, por defecto, Tomcat tiene deshabilitada la opción de “interacción con el escritorio”. Esta era la razón por la cual el navegador no era ejecutado correctamente.

La manera de corregir este problema es yendo a las propiedades del servicio de Tomcat (accesibles desde Tomcat o desde las propiedades de servicios de Windows) y desde allí a la pestaña “Log on”. En esta pestaña hay que habilitar la opción “Allow service to interact with desktop” (ver la siguiente imagen) y una vez hecho esto reiniciar el servicio. Ahora Hudson debería ser capaz de lanzar cualquier navegador (o programa en ventana) sin problemas.

Integración de JSUnit y Hudson

Etiquetas: , , , , , ,