Estructura_de_SVN_de_GV7 [Guadalinex V7]

Aquí vamos a mostrar el nuevo esquema que usaremos en el SVN de GV7 para generar los paquetes con el sistema de integración. Hemos llegado a la conclusión de usar esta metodología para poder ir cambiando los paquetes en el control de versiones a un proyecto con varias ramas, una rama trunk que será la rama upstream (donde esta el código de la aplicación) y otras varias ramas para cada paquetería especifica (GV6, GV7, Debian, Karmic,..)

Además poseeremos una rama "unstable" la cual es la rama principal de la paquetería, ésta rama estará sólo en LaunchPad ya que vamos a trabajar con bzr directamente y luego exportamos a Subversion. En esta rama "unstable" se irá trabajando para introducir cambios en ésta, como por ejemplo parches. Esquema del SVN

{SVNGV7.jpeg|SVNGV7}}

Por un lado tenemos la carpeta /apps donde alojaremos el código upstream del proyecto concreto, es decir, aquí es donde se exportará la rama trunk del proyecto en LaunchPad.

La carpeta /pkgs es la que monitorizará BuildBot para chequear si existe un cambio y construir el paquete nuevo. En esta carpeta ahora almacenaremos dos tipos de paquetes distintos:

-Paquetes nuevos: Estos paquetes serán los paquetes que empecemos a cambiar con la nueva metodología de separar upstream de paquetería, aquí sólo se alojará las ramas de paquetería. -Paquetes nativos/antiguos: Estos paquetes serán los paquetes nativos o antiguos a los que no le realicemos ninguna modificación con lo cual no usarían la nueva metodología aún.

En la parte de los paquetes nuevos, el BuildBot va a funcionar con un nuevo esquema, para cada paquete, BuildBot usara uuscan el cual buscará dentro del archivo debian/watch donde está alojado el tarball del código upstream, descargándolo y pasando el paquete completo (upstream+paquetería) a pbuild para que este lo construya. Por otro lado, si son paquetes nativos/antiguos, BuildBot seguirá funcionando como en anteriores versiones.

Por lo tanto en el directorio /pkgs irán únicamente los tags de paquetería.

Actualización de código Upstream

Cada vez que se lleve a cabo una actualización en el código de upstream, debemos realizar un nuevo tag con una nueva versión de upstream. Después generaremos un nuevo tarball el cual lo subiremos al release de la serie trunk.

Una vez subido este nuevo tarball ya no nos tendremos que preocupar por el introducirlo en el sistema de generación (también se actualizará en el svn pero no es necesario, es más por mantener el histórico) ya que el archivo watch se encargará de descargar el último tarball y construir el paquete con éste.

Veamos un ejemplo, actualizamos el código de upstream de getapixel debido a que tenía un bug y hemos solucionado éste. Lo primero que haremos será generar el nuevo tarball, suponemos que la versión antes de la actualización era 0.0.3, en este caso el paso a realizar es el siguiente

gv7@gv7-laptop:~/Proyectos/getapixel/trunk$ bzr export ../getapixel-0.0.4.tar.bz

Con esto obtenemos un tarball en la carpeta del proyecto, ahora debemos subir este nuevo tarball al release de LaunchPad para que el BuildBot sea capaz de encontrar este nuevo tarball y construir con él.

Lo primero que nos tenemos que hace es firmar nuestro tarball con la clave GPG del usuario que va a subir el archivo. Para ello debemos hacer lo siguiente

gv7@gv7-laptop:~/Proyectos/getapixel$ gpg --armor --sign --detach-sig getapixel-0.0.4.tar.bz

Esto nos creará un nuevo archivo llamado getapixel-0.0.4.tar.bz.asc. El siguiente paso es irnos a la serie trunk de nuestro proyecto y crear un release, para ello hacemos click en el enlace "Create release" el cual nos llevará a una pantalla como la siguiente

{releaselp.jpeg|releaselp}}

Añadimos la release a un nuevo milestone (clickando sobre "Create Milestone"), a este nuevo milestone le pondremos el nombre de la nueva versión, es decir, 0.0.4. Añadimos una fecha de publicación y creamos la release.

Ahora la siguiente pantalla que nos aparecerá es la de release, más abajo tenéis un botón con el titulo "Add Download File", haced click en este para subir el tarball

{addfile.jpeg|}}

Ahora tendremos la siguiente pantalla:

{uploadfile.jpeg|}}

Aquí debemos poner en descripción el texto tarball, en file seleccionamos nuestro tarball, en este caso getapixel-0.0.4.tar.gz, mientras que en GPG signature seleccionaremos la firma, es decir el fichero getapixel-0.0.4.tar.gz.asc. En file content type dejamos Code Release Tarball y subimos finalmente el tarball

Ya queda sólo actualizar la rama lucid con una nueva entrada de changelog y actualizar el tag de lucid en el SVN para que BuildBot se de cuenta del cambio y construya la nueva versión del paquete. Para ello nos vamos a nuestra rama de bazaar en local de lucid del paquete getapixel, una vez allí actualizamos el changelog

gv7@gv7-laptop:~/Proyectos/getapixel/lucid$ dch -i

Añadiendo la siguiente entrada

getapixel (0.0.4-0guada1) lucid; urgency=low

• Updated new upstream version

-- Guadalinex Developer 1 developer1@correo.com Fri, 30 Apr 2010 11:34:42 +0200

'( El usuario "Guadalinex Developer 1 developer1@correo.com" es un ejemplo, cada desarrollador deberá poner el suyo)''

Una vez hechos los cambios commiteamos estos cambios tanto a LaunchPad como a SVN para ello hacemos los siguientes comandos

gv7@gv7-laptop:/Proyectos/getapixel/lucid$ bzr ci -m"New upstream version" gv7@gv7-laptop:/Proyectos/getapixel/lucid$ bzr tag getapixel-0.0.4-0guada1 gv7@gv7-laptop:/Proyectos/getapixel/lucid$ bzr push gv7@gv7-laptop:/Proyectos/getapixel/lucid$ bzr push HTTPDELSVN/getapixel/tags/getapixel-0.0.4-0guada1

'Para poder realizar el push al SVN debemos tener instalado el paquete bzr-svn''

Y con todo éste proceso BuildBot se entera y lleva a cabo la construcción del nuevo paquete.