GitHub Actions – Starter post

GitHub Actions es el sistema de integración continua de GitHub

¿Qué es integración contínua?

Básicamente la integración continua es un sistema de automatización para verificar «la calidad de nuestro código y que esté bien formado». Además permite que los cambios que el equipo de desarrollo vaya implementando se puedan llevar a producción rápidamente. Es un poco todo 😅.

Dicho de forma un poco mas académica. El objetivo de la integración continua es la verificación e integración de los cambios de código llevados a cabo por diferentes contribuidores.

En un escenario normal tendremos a un equipo de desarrollo trabajando sobre un repositorio online, utilizando las operaciones habituales como creación de ramas, pushes, etc… A continuación se configurará un proceso que levante una máquina virtual donde se desplegará nuestro proyecto, pase los tests y si todo va bien proceda a pasar los cambios a producción.

Este proceso se iniciará cada vez que se produzca un cambio en el código (un push) por eso lo de «integración continua» 🔁.

¿Por qué voy a meterme en ese lio?

La integración continua le da importantes ventajas tanto a equipos de desarrollo como a proyectos individuales. El código debe de probarse en un entorno diferente al local. Ya sabemos que en nuestro ordenador personal todo funciona, pero la ley de Murphy es cruel y en el momento en que pasamos nuestro código a producción (o un profesor lo está corrigiendo) ocurren errores y se nos complica el día.

La filosofía subyacente es que el código pueda probarse en un entorno neutro, con una instalación limpia en el que todos los integrantes de un equipo de desarrollo tengan la certeza de estar trabajando en el mismo contexto. Si se pasan todas las pruebas quiere decir que nuestros cambios son correctos y funcionan (👍 eso ya es mucho) además podemos automatizar el despliegue en producción.

¿Qué necesito para empezar?

• Un repositorio en GitHub,
• Crear un archivo de configuración donde indiquemos que características va a tener la máquina virtual que queramos desplegar, que instrucciones debe ejecutar y cuando debe hacerlo.

Guía de términos

• Archivo Workflow: Archivo de configuración donde se define el flujo de trabajo de tu GitHub Actions. Está escrito en YAML (En esta entrada del blog se explica la sintaxis de este lenguaje, es bastánte sencillo cuando se entienden un par de particularidades) y tiene que encontrarse dentro de tú repositorio en el directorio📁 .github/workflows (Ojo con el punto en .github un error común es omitir el «.» al confundirlo con una errata). Cada archivo con la extensión .yaml que se encuentre en ese directorio define un flujo de trabajo diferente.
• Action: Un programa reutilizable que puede ser utilizado en workflows. Las actions pueden instalar software en un enviroment (maquina virtual), configurar el proceso de autentificación o automatizar operaciones más complejas. Una ventaja de GitHub actions es que se pueden encontrar acciones predefinidas en el GitHub Marketplace lo que simplifica mucho el trabajo🤩 o crear las tuyas propias y compartirlas con la comunidad.
• WorkFlow (Flujo de trabajo): Un proceso automatizado configurable que puedes utilizar en un repositorio para compilar, testear, empaquetar, lanzar o implementar tu proyecto. Un Workflow está construido por uno o más trabajos y pueden ser implementados por diferentes eventos de GitHub.
• Jobs (trabajos): Lista de trabajos que se ejecutan como parte del Workflow. Cada trabajo se lanzará independientemente del resto y correrá en una máquina virtual diferente. Los trabajos puede tener un nombre (name) que ayude a identificarlo en los logs y en la UI. Jobs contiene una serie de pasos (steps) que se ejecutarán en orden.

Ejemplo archivo Workflow

Vamos a examinar las distintas partes de un archivo workflow 🔍. Utilizaremos uno muy sencillo pero suficiente para aprender las bases.

name: Primer workflow
on:
  push:
    branches: [main]
jobs:
  saludo:
    runs-on: ubuntu-latest
    name: Saludo y despedida (nombre Job)
    steps:
    - name: Mostrar mensaje1 (nombre step 1)
      run: echo "Hola Mundo"
    - name: Mostrar mensaje2 (nombre step 2)
      run: echo "Adios Mundo"

Lo primero que podemos detectar es que tiene una estructura definida que consta de 3 apartados

• name: Se da nombre al workflow que se mostrará en la pestaña actions de nuestro repositorio.
• on: Aquí se definen los eventos que deben ocurrir en GitHub que activen el workflow. Por ejemplo puedes configurar un workflow para que cuando se produzca un push o un pull request en tu repositorio, el código y los tests se ejecuten en un entorno de integración continua. Además, puedes añadir restricciones adicionales en esos eventos como restringir la ejecución únicamente cuando se cambien determinados archivos o se haga un push a una rama concreta.  Este workflow se ejecutará cada vez que se haga un push a la rama main del repositorio.
• jobs: La lista de trabajos de este workflow (Aquí está la chicha). Este archivo tiene un único trabajo denominado «saludo» que tiene 2 steps.
  • runs-on: Especificamos el sistema operativo en el que se va a ejecutar este trabajo.
  • name: El nombre que tiene el job en este ejemplo es «Saludo y despedida (nombre Job)».

Ya hemos creado nuestro primer workflow 👌. Hay que reconocer que es extremadamente simple y poco (vale, nada) util pero cumple con su función que no es otra que comprender las bases de esta sistema. En posteriores posts hablaremos de las posibilidades que nos da GitHub Marketplace y cómo nos va a ayudar a crear workflows utiles, de calidad, de forma sencilla y rápida.