Travis CI 2021

El funcionamiento básico de Travis CI es clonar el repositorio de GitHub a un nuevo entorno virtual y llevar a cabo una serie de tareas para construir y probar tu código. Si alguna de estas tareas falla, el build se considera broken. Si no falla ninguna tarea, el build se considera passed y Travis CI puede desplegar tu código a un servidor web, por ejemplo. A continuación vamos a ver lo que hay que hacer para habilitar el sistema de integración continua y describiremos algunos conceptos básicos de Travis CI.

Conceptos básicos

En Travis CI hay 4 palabras que tienen un significado específico (obtenido de https://docs.travis-ci.com/user/for-beginners):

job

Un proceso automatizado que clona tu repositorio en un entorno virtual y realiza una serie de phases como compilar el código, ejecutar tests, etc. Un job falla si el código que devuelve la fase script no es cero.

phase

El conjunto de pasos secuenciales de un job. Por ejemplo, la fase install viene antes de la fase script, que viene antes de la fase opcional deploy. Las fases de Travis CI son las siguientes:

1. OPTIONAL Install apt addons
2. OPTIONAL Install cache components
3. before_install: instalar paquetes del SO necesarios para la construcción del proyecto
4. install: instalar las dependencias (librerías) que sean necesarias para la construcción del proyecto
5. before_script
6. script: ejecutar el script de construcción del proyecto.
7. OPTIONAL before_cache: para limpiar la caché
8. after_success or after_failure: after_success se ejecutará si la construcción se realiza correctamente como generar la documentación. after_failure se ejecutará en caso de que la construcción falle.
9. OPTIONAL before_deploy
10. OPTIONAL deploy: desplegar la aplicación a una plataforma integrada con Travis CI como Heroku o Engine Yard.
11. OPTIONAL after_deploy
12. after_script

build

Un grupo de jobs. Por ejemplo, un build puede tener dos jobs, cada uno prueba un proyecto con una versión distinta de Java. Un build termina cuando todos sus jobs terminan. Una build se considera broken si uno o más de sus jobs termina con un estado que no es passed. Esto puede ocurrir por una de estas tres razones:

• errored: un comando en la fase before_install, install o before_script falló. En este caso el job termina inmediatamente.
• failed: un comando en la fase script falló. El job se ejecuta hasta que se termina
• canceled: un usuario cancela el job antes de que complete.

En https://docs.travis-ci.com/user/common-build-problems/ se recogen una relación de problemas comunes en la construcción de un proyecto y cómo resolverlo.

stage

Un grupo de jobs que se ejecutan en paralelo.

Infraestructura

Travis CI ofrece tres tipos de infraestructuras diferentes:

• Basada en máquinas virtuales. Es un Linux Ubuntu ejecutándose en una máquina virtual completa.
• OS X. Para probar software que necesite el entorno OS X para funcionar.
• Basada Windows. Ahora mismo soporta la versión 1803 de Windows Server.

El fichero .travis.yml

Como ya hemos comentado, toda la información sobre cómo realizar cada job se especifica en un fichero .travis.yml que debe estar en el raíz del repositorio en cuestión. En su forma más básica, este fichero debe especificar el lenguaje utilizado en el proyecto para que cargue las librerías adecuadas en el entorno de ejecución y lo que se debe hacer en cada una de las fases descritas anteriormente. No es necesario especificar acciones en todas las fases.

De este modo, como nuestro proyecto Decide está en python, el fichero .travis.yml podría quedar de la siguiente forma:

language: python 
python: 
- "3.6"
env: 
- DJANGO=2.0 DB=postgres
before_install: 
- cd decide
install: 
- pip install -r ../requirements.txt
script: 
- python manage.py test

...

En este caso, estamos especificando que queremos utilizar la versión 3.6 de Python; indicamos un par de variables de entorno que son necesarias para el funcionamiento de la aplicación, y ejecutamos los comandos necesarios para:

• Moverse al path adecuado antes de la fase install (cd decide)
• Instalar las dependencias que necesita el proyecto para funcionar en la fase install (pip install -r ../requirements.txt)
• Lanzar las pruebas en la fase script (python manage.py test)

Soporte a base de datos

Es frecuente que una aplicación requiera de bases de datos u otros servicios externos para poder probarse. Travis CI tiene soporte de serie para las bases de datos más habituales como MySQL, PostgreSQL, MongoDB o ElasticSearch. La lista completa se puede encontrar en https://docs.travis-ci.com/user/database-setup/ así como la forma de configurar cada una de ellas que, de nuevo, se realiza a través de .travis.yml. Por ejemplo, para configurar postgresql hay que añadir a .travis.yml lo siguiente:

...
services:
  - postgresql

before_script:
 - psql -c "create user decide with password 'decide'" 
 - psql -c "create database decide owner decide"
 - python manage.py migrate

La primera instrucción le dice a Travis CI que instale postgresql pues lo vamos a utilizar y la segunda instrucción le indica que cree un usuario, la base de datos y las tablas de la base de datos (python manage.py migrate) justo antes de la fase de script. Estos pasos (crear usuario, base de datos y tablas) también podrían ir ubicados en una fase anterior como before_install y son específicos de cada aplicación en cuestión. El resto de bases de datos se configuran de una forma bastante similar.

También se puede definir información adicional de configuración. Por ejemplo:

...
services:
  - postgresql
addons:
  postgresql: "9.6"
global:
  - PGPORT=5432

before_script:
 - psql -c "create user decide with password 'decide'" 
 - psql -c "create database decide owner decide"
 - python manage.py migrate

En este caso, la segunda instrucción le indica cuál es la versión de postgresql que se va a utilizar; la tercera especifica la configuración sobre el puerto donde va a estar escuchando. Las restantes son iguales al caso anterior.

https://raw.githubusercontent.com/jagalindo/decide/master/.travis.yml

Configuración de la aplicación

La configuración del entorno donde se van a ejecutar las pruebas y la base de datos es sólo la mitad del recorrido. Una vez configurado, es necesario indicar a nuestra aplicación cuál es la base de datos que vamos a utilizar y el resto de opciones de configuración. Para ello, siguiendo el esquema propuesto en , vamos a crear un fichero con la configuración para travis y luego vamos a copiarlo al principio de la fase before_script.

El fichero de configuración para travis sería el siguiente:

local_settings.travis.py

---

ALLOWED_HOSTS = ["*"]

# Modules in use, commented modules that you won't use
MODULES = [
    'authentication',
    'base',
    'booth',
    'census',
    'mixnet',
    'postproc',
    'store',
    'visualizer',
    'voting',
]

APIS = {
    'authentication': 'http://localhost:8000',
    'base': 'http://localhost:8000',
    'booth': 'http://localhost:8000',
    'census': 'http://localhost:8000',
    'mixnet': 'http://localhost:8000',
    'postproc': 'http://localhost:8000',
    'store': 'http://localhost:8000',
    'visualizer': 'http://localhost:8000',
    'voting': 'http://localhost:8000',
}

BASEURL = 'http://localhost:8000'

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'postgres',
        'USER': 'postgres',
        'HOST': 'localhost',
        'PORT': '5432',
    }
}

# number of bits for the key, all auths should use the same number of bits
KEYBITS = 256

y lo copiamos con el nombre adecuado modificando el fichero .travis.yml tal como sigue:

...

before_script:
 - cp local_settings.travis.py local_settings.py
 - ...