7. GitHub Actions

Introducción

El despliegue continuo es desplegar las aplicaciones web lo más pronto posible: cada cambio que se sube al repositorio acaba en el servidor sin que nadie tenga que hacerlo a mano.

Para eso se usa un servidor de automatización: un programa que, cuando ocurre algo (un push a una rama, que alguien pulse un botón, una hora concreta), ejecuta solo una lista de pasos escrita de antemano. Los pasos son los que haríamos nosotros a mano:

Descargar el código del repositorio.
Compilarlo y pasar los tests.
Construir la imagen Docker.
Conectarse al servidor y arrancar la nueva versión.

Si un paso falla, se para ahí y avisa: lo que no compila o no pasa los tests no llega al servidor.

Existen muchas formasde hacerlo, antiguamente se hacía con una herramienta de software libre llamada Jenkins pero actualmente se usan las acciones de GitHub o GitLab , etc.

Workflows

Un workflow es un fichero YAML dentro de la carpeta .github/workflows/ del repositorio. GitHub lee esa carpeta en cada push: no hay que darlo de alta en ningún sitio. El fichero tiene tres partes:

on: cuándo se ejecuta. push con branches cuando se sube algo a esa rama; workflow_dispatch añade un botón Run workflow en la pestaña Actions para lanzarlo a mano.
jobs: los trabajos que hay que hacer. Cada uno se ejecuta en un runner, el que diga runs-on: con ubuntu-latest, un Ubuntu que GitHub crea para la ocasión y tira al acabar (Runners).
steps: los pasos de cada trabajo, en orden. Cada paso tiene un name y hace una de dos cosas:
- run: órdenes de shell, como en una terminal. Con | se ponen varias líneas.
- uses: una acción ya hecha por otros, como actions/checkout@v7, que descarga el código del repositorio en el runner.

Lo que no debe estar en el repositorio (contraseñas, claves SSH, IPs) se guarda como secreto en Settings → Secrets and variables → Actions y se usa en el workflow con ${{ secrets.NOMBRE }}. GitHub lo oculta en los logs.

El runner arranca vacío: no tiene nuestro código hasta que se hace actions/checkout, y no tiene nada instalado aparte de lo que trae Ubuntu, así que lo que haga falta se instala en un paso.

Para compilar el proyecto Java y pasar sus tests cada vez que se sube algo a master, se añade al repositorio:

name: Compilar

on:
  workflow_dispatch:
  push:
    branches:
      - master

jobs:
  compilar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7

      - name: Instalar Java 21
        uses: actions/setup-java@v6
        with:
          distribution: temurin
          java-version: 21

      - name: Compilar y pasar los tests
        run: mvn -B package

actions/setup-java: el Ubuntu del runner no trae la versión de Java del proyecto; esta acción la instala.
mvn -B package: compila y pasa los tests. Si falla un test, el workflow sale en rojo. -B es el modo no interactivo, sin colores ni barras de progreso en el log.

Cada ejecución sale en la pestaña Actions del repositorio, con cada paso en verde o en rojo y su log. Si un paso falla, los siguientes no se ejecutan.

Runners

Un runner es el programa que ejecuta los jobs de un workflow: GitHub le pasa los pasos y él los va ejecutando y le devuelve el log. Dónde está el runner lo elige runs-on, y hay dos tipos:

Runner de GitHub (runs-on: ubuntu-latest): una máquina virtual que GitHub crea para cada job y tira al acabar. Es el del workflow de arriba.
Runner propio (runs-on: self-hosted): el mismo programa, pero instalado por nosotros en un servidor nuestro. Se queda siempre en marcha esperando trabajo.

	Runner de GitHub	Runner propio
Dónde se ejecutan los pasos	En una máquina de GitHub	En nuestro servidor
Hay que instalarlo y mantenerlo		✓
Empieza vacío en cada ejecución	✓
Ve la red del servidor		✓
Para desplegar necesita VPN, SSH y sus secretos	✓

Para compilar y pasar los tests, el runner de GitHub. Para desplegar en un servidor nuestro, un runner propio en ese servidor: los pasos se ejecutan allí mismo, así que el workflow se queda en lanzar deploy.sh.

Con el runner de GitHub

El runner está en Internet y el servidor en el instituto, así que para desplegar tendría que entrar por VPN y SSH, con las claves guardadas como secretos:

Con un runner propio

El runner está dentro del servidor. Es él quien pregunta a GitHub si hay trabajo, por HTTPS, como un navegador: no hace falta abrir ningún puerto ni VPN, y funciona aunque el servidor esté detrás del router del instituto.

Instalar un runner propio en Linux

Un runner se registra en un repositorio y solo ejecuta sus workflows. Se instala en el servidor con el usuario que va a desplegar, no con root:

En el repositorio, Settings → Actions → Runners → New self-hosted runner, con Linux y x64. GitHub muestra las órdenes de los pasos siguientes con el token ya puesto. El token caduca en una hora.

Descargarlo:

mkdir actions-runner && cd actions-runner
curl -O -L https://github.com/actions/runner/releases/download/v2.338.2/actions-runner-linux-x64-2.338.2.tar.gz
tar xzf ./actions-runner-linux-x64-2.338.2.tar.gz

Registrarlo en el repositorio. Pregunta el grupo, el nombre y las etiquetas: con Enter se queda lo que propone.
```
./config.sh --url https://github.com/lgonzalezmislata/Facturas --token AXQKZ7MBV3LN2RCYEUHJ4PDTD6Y2W
```
Dejarlo como servicio, para que siga en marcha al cerrar la sesión SSH y arranque solo al reiniciar el servidor:
```
sudo ./svc.sh install
sudo ./svc.sh start
sudo ./svc.sh status
```
En Settings → Actions → Runners tiene que salir como Idle.

El workflow de despliegue, en el repositorio del proyecto, se queda en clonar el repositorio de despliegue y lanzar deploy.sh:

name: Desplegar

on:
  workflow_dispatch:
  push:
    branches:
      - master

jobs:
  desplegar:
    runs-on: self-hosted
    steps:
      - name: Desplegar
        run: |
          rm -rf DesplegarFacturasDocker
          git clone https://github.com/lgonzalezmislata/DesplegarFacturasDocker.git
          cd DesplegarFacturasDocker && ./deploy.sh

Los pasos se ejecutan con el usuario que instaló el runner, y sin terminal para escribir la contraseña de sudo. Si deploy.sh usa Docker, ese usuario tiene que estar en el grupo docker (sudo usermod -aG docker $USER y reiniciar el servicio).

El runner propio no empieza vacío: lo que deja una ejecución sigue ahí en la siguiente, en actions-runner/_work. Por eso el workflow borra la carpeta antes de clonar.

Un runner propio solo en repositorios privados: en uno público, cualquiera que abra un pull request puede hacer que ejecute su código en tu servidor.

Más información:

About self-hosted runners: qué son y requisitos.
Configure the self-hosted runner application: svc.sh en Linux.

Ejercicios

Ejercicio 1

Añade a tu repositorio de Java el workflow compilar.yml. Comprueba en Actions que sale en verde; luego haz fallar un test, súbelo y comprueba que sale en rojo y en qué paso.

Ejercicio 2

Instala un runner propio para tu repositorio de Java en tu servidor como en Instalar un runner propio en Linux, como servicio, y comprueba que sale Idle.
Añade el workflow desplegar.yml adaptado a tu proyecto. Se ejecutará manualmente y cuando haya un cambio en master. Sube un cambio y comprueba que llega desplegado al servidor.