Buildbot 0.8.3 – Instalación y Configuración

Buildbot es un software de integración continua, que permite entre otras cosas, disponer de herramientas que automatizan el ciclo de la compilación / pruebas, requerido para validar los cambios en el código base de los proyectos de software.

La siguiente configuración de buildbot se encuentra orientada a un proyecto que posee (02) paquetes (base-files y canaima-llaves), pertenecientes al proyecto canaima y que fueron “clonados” por medio de git. La configuración fue efectuado con equipo arquitectura i386 bajo Debian 6.0 (squeeze)

Para el siguiente ejemplo, crearemos un proyecto de nombre ‘trucupei’ con (02) servidores, un master con la configuración de buildbot y el repositorio de fuentes (git) y un esclavo para la ejecución de los procesos de buildbot.

Los equipo a configurar son:

(01) un equipo maestro, el cual contiene la configuración de buildbot y el código fuente de los paquetes bajo git.

  • Nombre del equipo: buildbot
  • Dirección IP: 161.196.1.10
  • Ruta repositorio fuente: /srv

(01) Un equipo esclavo, el cual servirá para la ejecución de las instrucciones de buildbot en arquitectura i386

  • Nombre del equipo: Zamuro
  • Dirección IP: 161.196.1.11
  • Nombre del equipo ante buildbot: esclavo01
  • Contraseña: qwerty
  • Puerto de comunicación: 4484


Del lado de buildbot master (buildbot)
Instalación

operador@buildot:~$ sudo aptitude install buildbot

Configuración

1. Crear Proyecto. En nuestro lo crearemos en ‘/var/lib/buildbot’ con el nombre de ‘trucupei’:

operador@buildot:~$ sudo buildbot create-master trucupei

Buildbot creará una carpeta ‘trucupei’ con el siguiente contenido:

  • master.cfg.sample
  • buildbot.tac
  • Makefile.sample
  • public_html
  • state.sqlite

master.cfg, es un archivo de configuración escrito en Python. No es necesario saber Python para la configuración básica, sin embargo, se puede emplear las bondades de un lenguaje de programación para lograr mejoras.
El archivo ‘master.cfg’, puede ser construido desde ‘0’ o tomar como base el generado por buildbot, master.cfg.sample (se debe renombrar a master.cfg), en nuestro caso emplearemos un archivo de configuración elaborado por: Jesús Lara (phenobarbita)
Para la configuración, ademas del master.cfg, se construyeron dos (02) archivos con sintaxis en python adicionales, los cuales permiten separar la configuración de los procesos que maneja el master.cfg, para un mejor control en los cambios. Dichos archivos son:

  • config.py
  • slaves.py

Archivo de configuración master.cfg
ruta: /var/lib/buildbot/trucupei

# Diccionario que contiene la configuracion de buildmaster

c = BuildmasterConfig = {}

# inicialización de variables

c['slaves'] = []
c['change_source'] = []
c['schedulers'] = []
c['builders'] = []

Generalmente el archivo de configuración ‘master.cfg’ comienza con esta línea ‘c = BuildmasterConfig = {}’, la cual define un diccionario de Python accesible a través de “BuildmasterConfig” y “c”. Cuando Buildbot lea la configuración va a buscar “BuildmasterConfig”, nosotros emplearemos “c”.

##### Configuración de los esclavos
####### BUILD SLAVES CONFIGURATION

from slaves import slaves

for s in slaves.keys():
    b = BuildSlave(s, slaves[s]['passwd'])
    c['slaves'].append(b)

# puerto donde escuchan los esclavos
c['slavePortnum'] = info['slavePort']

En la primera línea se ‘carga’ el archivo slaves.py con la configuración de los equipos esclavos. En segundo lugar se define la lista de los equipos esclavos a utilizar.

En la primera línea se ‘carga’ el archivo slaves.py con la configuración de los equipos esclavos. En segundo lugar se define la lista de los equipos esclavos a utilizar.

Archivo de configuración slaves.py
ruta: /var/lib/buildbot/trucupei

# -*- python -*-
# ex: set syntax=python:
#

# Definición de esclavos

slaves = {}
slaves['esclavo01'] =  {'arch':'i386', 'dist':'squeeze', 'passwd':'qwerty'}

El archivo de configuración slaves.py, contiene el nombre del equipo ante buildbot, la arquitectura y la contraseña. En nuestro caso solo empleamos un equipo esclavo, el cual denominamos ‘esclavo01’, el cual compilara bajo arquitectura i386.

####### CHANGE SOURCE CONFIGURATION
#Definicion de repositorio y revision de los cambio

from buildbot.changes.gitpoller import GitPoller

for item in packages['list']:
    r = vcs['repository'] + item
    c['change_source'].append(GitPoller(r, branch=vcs['branch'], pollinterval=vcs['pollinterval']))

Aquí le indicamos a Buildbot, el repositorio, como la administramos (en nuestro caso con ‘git’), la lista de paquetes y el período de tiempo para ‘chequear’ los cambio o actualizaciones. Los parámetros de configuración se encuentran en el archivo ‘config.py’.
Extracto del archivo config.py
Ruta: /var/lib/buildbot/trucupei

#Lista de los paquetes
packages ={}
packages['list'] = ['base-files', 'canaima-llaves']

#Información sobre repositorio y controlador de versiones
# VCS info
vcs = {}
vcs['type'] = 'git'
vcs['url'] = "https://git.gitorious.org/canaima-gnu-linux/"
vcs['repository'] = '/srv/'
vcs['branch'] = 'master'
vcs['time'] = 60
vcs['pollinterval'] = 60

Un scheduler es responsable de definir cuando debe activarse proceso de construcción (definido en la fábrica) y quienes deben hacerlo.

####### SCHEDULERS CONFIGURATION

from buildbot.scheduler import Scheduler
from buildbot.schedulers import basic

s = Scheduler(name="estable",branch=vcs['branch'],treeStableTimer=vcs['time'],builderNames=builders.keys())
c["schedulers"].append(s)

En este caso en particular le estamos diciendo que el Scheduler llamado “estable” va a ver los cambios que se le hagan al trunk (branch=vcs[‘branch’], definido como ‘master’ en config.py), y escuchen cambios en el repositorio y no halla habido cambios en los últimos (vcs[‘time’], definido ’60’ segundos en config.py ) va a hacer que el builder (builders.keys()) haga un build.

####### BUILDERS CONFIGURATION

from buildbot.process import factory
from buildbot.steps import source
from buildbot.steps import shell
from buildbot.process.factory import BuildFactory
from buildbot.steps.source import Git
from buildbot.steps.shell import ShellCommand
from buildbot.steps.transfer import DirectoryUpload, FileDownload, FileUpload

# construir la lista de arquitecturas
arch = {}
for s in slaves.keys():
    vm = slaves[s]
    arch[vm['arch']] = 1

for a in arch.keys():
    e = []
    for s in slaves.keys():
        if slaves[s]['arch'] == a:
            e.append(s)
    arch[a] = e

En este caso, se recorre un arreglo con la información de los esclavos y la arquitectura asignada. Estos se encuentra definido en el archivo slaves.py.
En nuestro caso, hemos modificado en archivo original y dejado un solo esclavo para que procese la arquitectura i386.

from buildbot.config import BuilderConfig

builders = {}

for p in packages['list']:
    f = factory.BuildFactory()
    repo = vcs['repository'] + p
    f.addStep(ShellCommand(command="rm -rf *"))
    f.addStep(ShellCommand(command=["git", "clone", repo]))
    f.addStep(ShellCommand(command=["git", "checkout", "master"],workdir="build/"+p))
    f.addStep(ShellCommand(command=["git-dch", "--since=HEAD^"], workdir="build/"+p))
    f.addStep(ShellCommand(command=["git-buildpackage", "--git-ignore-new", "-us", "-uc", "-rfakeroot"], workdir="build/"+p))

En este caso, se definen los procesos que serán llevados a cabo por el sistema de construcción, por cada una de los paquetes que se hayan declarados (packages[‘list’], definidos en el archivo config.py)

En nuestro caso, el primer proceso es asegurar limpiar la carpeta de trabajo, luego se procede a ‘clonar’ el contenido del repositorio fuente(*), se comprueba el repositorio clonado, Se leen los ‘commit’ de los paquetes para general los changelog en debian y finalmente se procede a generar el paquete binario “.deb”.

(*) Es importante que los repositorios fuentes se encuentre disponible para el equipo esclavo, en nuestro caso se hizo disponible por medio de NFS. Leer sección ‘compartir fuentes por NFS‘.

    for a in arch.keys():
        n = p + '-' + a
        builders[n] = arch[a]
        b = BuilderConfig(name=n,factory=f,slavenames=arch[a])
        c["builders"].append(b)

Cada fábrica es asociada a un sistema de construcción (build) y a su ves en el equipo esclavo que llevará a cabo el proceso. En nuestro caso, se ejecutará tanta veces como paquetes tengamos en la lista (packages[‘list’]) y como arquitectura tengamos definidas (‘arch’), para este ejemplo definimos una sola arquitectura (archivo slaves.py).

Para presentar el estado de los procesos ejecutados, se cuentan con varias alternativas:

####### STATUS TARGETS

from buildbot.status.html import WebStatus
from buildbot.status.web.authz import Authz
from buildbot.status import words
from buildbot.status import mail

c["status"] = []

### web server & project info ###
# WebServer configuration
if web['enable'] == True:
    c["status"].append(WebStatus(http_port=web['port'], allowForce=True))
    c['buildbotURL'] = web['url']

Le más común es el webserver, en nuestro caso le indicamos que levante el Webserver web [‘url’] por el puerto web[‘port’] (ambos configurados en el archivo config.py), donde va a estar la información sobre los distintos builds.

# mail configuration
if irc['enable'] == False:
    c['status'].append(mail.MailNotifier(fromaddr=email['mailfrom'], sendToInterestedUsers=False, \
    extraRecipients=email['recipients'], useTls=True, relayhoshost="smtp.gmail.com", smtpPort=587, \
    smtpUser="usuario@gmail.com", smtpPassword="123456"))

En esta caso, podemos configurar una cuenta (usuarios@gmail.com), para que nos notifique por correo electrónico la información de los distintos builds.

####### PROJECT IDENTITY
# Identificación del Proyecto 

c['projectName'] = info['project']
c['projectURL'] = info['url']

Por último encontramos la información del proyecto, en nuestro caso se maneja mediante la variable info[‘project’] y info[‘url’] (ambas configuradas en el archivo config.py.

Enlaces:
http://blog.cuerty.com/?s=buildbot&x=0&y=0
http://www.sffjunkie.co.uk/files/temp/buildbot/html/configuration.html?highlight=shellcommand#build-factories
https://github.com/isotoma/shenzhou/blob/master/shenzhou/shenzhou.cfg
http://forja.guadalinex.org/webs/guadalinexv5/doku.php?id=sistema_de_generacion

Anuncios

Un comentario en “Buildbot 0.8.3 – Instalación y Configuración

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s