Ir al contenido principal

Asamblea: 2018-09-12

El Miércoles pasado tuvimos la primera asamblea del curso escolar. Salieron muchas ideas, que hemos recogido en el acta, que se puede consultar donde siempre.

Ahora toca la siguiente parte, que es sacar acciones de todas estas ideas. Va a ser un trabajo interesante, al que como siempre invitamos a todes a venir, hayan venido o no alguna vez a la Brecha Digital. De hecho, si no han venido nunca se agradecerá especialmente, por que un tema recurrente fue el de facilitar la entrada de personas y proyectos.

Para facilitar la jornada de trabajo, es importante traerse pensado todos los puntos tocados en la anterior asamblea, incluido como organizar todo.

El orden del día es el siguiente:

  • Puesta en antecedentes En la anterior asamblea sacamos una serie de objetivos que tenemos que organizar. El resumen de estos son:
  • Incidir en el barrio
  • Romper la barrera de género
  • Terminar la primera iteración del empaquetado de infraestructuras (nombre temporal)
  • Cambios en como hacemos las charlas
  • Facilitar la entrada de personas a BD
  • Facilitar la entrada de proyectos a BD

  • Definir método de trabajo Los objetivos anteriores son muy genéricos y requieren de cierta organización para llevarlos a cabo. Por ello, antes de nada, tenemos que pensar como organizarlo. En esta sección debatiremos sobre ello.

  • Crear tareas y asignarlas a quien pueda Pues eso, vemos que tareas concretas podemos sacar, las creamos y vemos si alguien puede hacerlas.

Un saludo!

Asamblea: 2018-09-05

Este Miércoles, 5 de Septiembre vamos a reunirnos en Asamblea.

Esta va a ser un poco más especial que el resto de asambleas, ya que en ella debatiremos sobre el rumbo del colectivo durante este año.

Por ello es importante que os traigáis pensadas las siguientes cuestiones:

  • ¿Qué esperas de la Brecha Digital este año?
  • ¿Qué cambiarías/mejorarías de la Brecha Digital?

Aprovecharemos para planificar que haremos este mes para comenzar el curso. Animamos a participar a todo el mundo que esté interesado puesto que no son densas y se tratan temas técnicos.

El orden del día es el siguiente:

  • Rotado de responsabilidades
  • Elección de las temática de cada miércoles
  • Anuncio sobre temas de actualidad
  • Revisión de las tareas del mes pasado
  • Plan de tareas para este mes
  • Varios

Para agilizar el planning del mes siguiente, es muy recomendable revisar las incidencias abiertas y pensar en qué podríamos centrarnos.

Un saludo!

Volvemos a las andadas

Aunque las vacaciones de verano se estén acabando para quien las tenga y eso suponga volver a la rutina para la mayoría de los mortales, no todo van a ser malas noticias porque también vuelve La Brecha Digital a reunirse.

Tras un verano poco activo, vamos a retomar las actividades del Hacklab, este miércoles 29 de Agosto, como siempre a las 19:30 en el Centro Social de La Brecha, en Vallecas.

La idea es volver a vernos las caras y pasar un buen rato antes de la asamblea de la semana que viene. Así que contamos con vuestra asistencia.

Un saludo veraniego :D

Anuncio de verano veranete

Aunque San Lorenzo se está portando y no nos está castigando, desde La Brecha Digital no podemos negar que el veranito ya ha llegado.

Esto se está notando como todos los años en una reducción en la presencia a las sesiones. Por ello creemos que no merece la pena que la gente se prepare sesiones para que solo vayan unas pocas personas.

Y tampoco nos engañemos, despues de un añito de curro también nos apetece descansar un poco de la obligación de abrir todos los miercoles.

Por ello colgamos el cartel de vacaciones hasta la asamblea del 2018-09-05.

Significa esto que no nos vamos a reunir en la brecha digital hasta entonces?

No exactamente, los que estamos tirando más del carro últimamente nos queremos quitar la "obligación" de abrir, no obstante es probable que una o dos veces al mes nos reunamos para hacer taerillas o algún cineforum.

Puede que de ser así lo plasmemos en el blog, pero es más probable que las quedadas se organicen de manera improvisada a través del canal de jabber brechadigital@sala.chat.cslabrecha.org.

Así que si quieres ir un miercoles, métete en el canal y dínoslo, si somos gente suficiente puede que nos acerquemos.

Buen verano!

Asamblea: 2018-07-11

Este míercoles, 11 de Julio vamos a reunirnos en Asamblea.

Aprovecharemos para planificar que haremos este mes con el comienzo del verano. Animamos a participar a todo el mundo que esté interesado puesto que no son densas y se tratan temas técnicos.

El orden del día es el siguiente:

  • Rotado de responsabilidades
  • Elección de las temática de cada miércoles
  • Anuncio sobre temas de actualidad
  • Revisión de las tareas del mes pasado
  • Plan de tareas para este mes
  • Varios

Para agilizar el planning del mes siguiente, es muy recomendable revisar las incidencias abiertas y pensar en qué podríamos centrarnos.

Un saludo!

Mantener Git limpio

Si has utilizado git de manera habitual estarás familiarizado con los repositorios con miles de ramas ya mergeadas, tanto en local como en el repositorio remoto.

Esto hace que por ejemplo cuando quieras hacer un merge request sea muy pesado buscar la rama que quieres mergear.

En esta tarea nos propusimos revisar como hacer una limpieza automática.

Como aún le estamos quitando el polvo a nuestra nueva mascota, drone (os podéis logar con los credenciales de gitea), pensamos que estaría bien que un paso de la integración continua fuese el limpiar las ramas mergeadas.

Nos pusimos manos a la obra, hicimos un docker para que drone lo lanzase durante este paso. Este tenía git y ssh ya que como es un proceso automático no se podía clonar con credenciales https.

Por lo tanto el docker cogía la clave ssh de unos secretos de drone para hacer el pull y el push necesario para borrar las ramas. No obstante por problemas de conectividad no terminó de funcionar. Además de que habría que dar manualmente permiso al usuario de gitea de integración continua a cada repositorio para que este pudiese modificar el repositorio.

Ello hizo que desechasemos a priori esta aproximación. Lo siguiente que pensamos fue hacer un cron job que borrase localmente las ramas mergeadas en el servidor donde tenemos gitea. El problema es que la información almacenada son repositorios git bare, no lo que ven los clientes, por lo tanto todas las herramientas o comandos de limpieza fallaban.

Por último se nos ocurrió que lo más fácil era instalar un hook de git en los clientes. Como es pesado agregar el hook en cada repositorio que utilicemos se pueden establecer hooks genéricos para todos los repositorios con el siguiente comando:

git config --global core.hooksPath /path/to/hooks

Donde /path/to/hooks/ puede ser ~/.git/hooks. La desventaja de esta medida es que se desactivan los hooks de los repositorios en particular, a no ser que los actives manualmente (y entonces no funcionarán los globales).

Utilizaremos el hook post-merge que se dispara cuando tras hace run git pull hay alguna rama que se ha mergeado.

Dentro de este script podemos poner cualquier script nosotros utilizaremos dos herramientas git-sweep y git-extras para instalarlas haremos:

pip install --user git-sweep
sudo apt-get install git-extras

git-sweep es un programa para borrar ramas mergeadas en remoto, y utilizaremos el comando git delete-merged-branches de git-extras para borrar las ramas en local.

Por lo tanto el archivo ~/.git/hooks/post-merge quedará como:

#!/bin/sh

git-sweep cleanup --force
git delete-merged-branches

Por lo que vemos, la ñapa es bastante fea. Ya va siendo hora de que esta "feature" tan necesaria esté integrada en los gestores de git como gitea o gitlab.

Asamblea: 2018-07-04

Este míercoles, 4 de Julio vamos a reunirnos en Asamblea.

Aprovecharemos para planificar que haremos este mes con el comienzo del verano. Animamos a participar a todo el mundo que esté interesado puesto que no son densas y se tratan temas técnicos.

El orden del día es el siguiente:

  • Rotado de responsabilidades
  • Elección de las temática de cada miércoles
  • Anuncio sobre temas de actualidad
  • Revisión de las tareas del mes pasado
  • Plan de tareas para este mes
  • Varios

Para agilizar el planning del mes siguiente, es muy recomendable revisar las incidencias abiertas y pensar en qué podríamos centrarnos.

Un saludo!

Integración Continua con Drone

Hace poco que hemos empezado a usar Drone como plataforma de integración continua. A continuación veremos que es la integración continua, historia y usos.

La integración continua es la práctica que consiste en hacer integraciones automáticas de un proyecto lo más a menudo posible para detectar fallos cuanto antes, entendiendo integración como compilación (de ser necesaria) y ejecución de pruebas del proyecto. Esta integración suele activarse desde el control de versiones del proyecto, como por ejemplo git. La idea es que cada vez que se realiza un evento (un push, un pull request, …) se ejecuta la integración. Lo bueno es que se puede escoger qué se ejecuta en cada evento. Por ejemplo, los tests unitarios suelen ser bastante ligeros, y aún siendo varios cientos, tardan pocos segundos en ejecutarse. Por lo tanto, tiene sentido que se ejecuten con cada push. Pero, por ejemplo, replicar una infraestructura es más costoso, aún con tecnologías como docker. Por lo tanto, tendría sentido ejecutar pruebas de integración con docker solo en los merge request.

Se entenderá todo mejor con un ejemplo. Antes de eso, explicaré brevemente como lo hemos instalado. Como ya sabrá quien haya venido a alguna asamblea, en La Brecha Digital tenemos un proyecto, que es ansibilizar y dockerizar el un servidor con todos los componentes que queremos. Uno de estos es drone. Por lo tanto, si se quiere instalar, se puede usar el rol deploy-docker, que es un rol que hemos desarrollado para desplegar contenedores docker que se puedan gestionar como servicios de systemd. Las lineas exactas se pueden consultar en nuestro playbook.

Suponiendo que tenemos drone ya instalado y integrado con algún servidor git (en nuestro caso gitea, aunque hay más opciones), veamos como empezar a usarlo. Un detalle que hace que drone mole más que otros engendros gigantes, deformes y javosos como Jenkins, es que tiene una cli funcional muy simple de usar. Una vez logueado en tu servidor drone, hay una sección que se llama Token. En esta saldrá algo como esto:

export DRONE_SERVER=https://drone.cslabrecha.org
export DRONE_TOKEN=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.aa29iwidHlwZSI6InVzZXIifQ.XtTbzRLeZngWiXAd_TzOyfYEKAQ8OF_9xJzYeH4J3q8
drone info

Solo hay que copiarlo y ejecutarlo en la shell y ya se puede usar la cli. Para activar un repositorio, solo hay que ejecutar:

drone repo add La_Brecha_Digital/brechadigital-web

Y ya. Al añadirlo como repositorio, automáticamente configura el repositorio git, por lo que todos los eventos push del repositorio activaran el pipeline de drone, una vez este exista. Para ver un ejemplo real, vamos a examinar el repositorio para crear la imagen de docker de nikola que hemos hecho. El repositorio consta de tres ficheros, un README, un Dockerfile y un .drone.yml. El fichero .drone.yml es el que contiene el pipeline del repositorio. A fecha de hoy, contiene esto:

pipeline:
  # Build the image when on pull request
  build:
    image: docker
    commands:
      - docker build -t testing/nikola .
      - docker rmi testing/nikola
      - docker system prune -f
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    when:
      event: pull_request
  # Publish the image to the registry
  build-push:
    image: plugins/docker
    repo: r.cslabrecha.org/nikola
    registry: r.cslabrecha.org
    tags: latest
    secrets: [docker_username, docker_password]
    when:
      branch: master
      event: push
branches: master

Se puede apreciar que hay dos partes, por así decirlo. Uno seria build y el otro build-push. Los nombres son bastante descriptivos, uno construye la imagen y el otro construye la imagen y la pushea al registry. La diferencia principal son los when. Estos parámetros son los que deciden cuando se ejecuta un build. En el primer caso, se ejecuta solamente cuando el evento recibido es un pull request. En el caso del segundo, cuando es un push a master, es decir, cuando el pull request se ha mergeado correctamente.

Cuando se activa un pipeline en un evento, se añade un botón al lado del commit. Cuando está en progreso, tiene una redonda amarilla. Cuando termina correctamente e incorrectamente, respectivamente, se ve así:

img

img

Es importante fijarse en esto cuando se siguen políticas estrictas de calidad, por que de momento gitea no permite bloquear el pull request (o peticion de mergeo) hasta que la integración contínua no termine correctamente.

Quien tenga curiosidad, puede echar un ojo al que tenemos montado. Este build en concreto es uno de construcción de la página web. Se pueden ver los stages abajo a la izquierda (clone, builder), y a la derecha se ve el log de las órdenes que ejecutan el stage. También se puede ver más información relevante, como cuando se ejecutó el build, el commit que ejecutó, el estado, …

Y con esto se puede empezar a usar drone. Aviso que la documentación disponible deja bastante que desear. Parece que apunta mucho al rollo enterprise, pero hay que tener en cuenta que el proyecto es relativamente joven, con suerte mejorará. Cualquier duda, se puede comentar en la sala de xmpp que se puede consultar en la sección de contacto.