Saltar a contenido

Integración continua — Gitea Actions

Traducción automática del original francés.

El parque ejecuta sus flujos de trabajo con act_runner, en la máquina virtual vm-compute-01, en modo dind: las tareas se ejecutan en el demonio Docker del runner, no en el del host.

El flujo de un "push"

flowchart LR
    dev["Poste<br/>git push"]
    gitea["Gitea<br/>vm-docker:3303"]
    runner["act_runner<br/>vm-compute-01"]
    job["Job dans<br/>node:20-bookworm"]
    hote["vm-docker<br/>deploy-hook.sh"]

    dev --> gitea
    gitea -.->|"le runner interroge,<br/>Gitea ne pousse pas"| runner
    runner --> job
    job -->|"ssh, clé verrouillée<br/>par command="| hote
    hote --> ok["git pull + build<br/>+ vérification"]

El runner recupera la tarea mediante una consulta larga: Gitea nunca la contacta. Por lo tanto, la URL con dirección IP directa en su configuración — a través de Caddy, esta consulta permanente se asemeja a un escaneo y podría ser bloqueada por CrowdSec.

La trampa más costosa: el alcance de un runner

Un act_runner tiene un alcance único, fijado a la instancia — instancia, organización, usuario, o un único repositorio. No cambia después.

flowchart TB
    subgraph hote["vm-compute-01"]
        r1["rtx-runner<br/>portée : dépôt homelab-vault"]
        r2["docs-runner<br/>portée : dépôt homelab-docs"]
    end

    v["Dépôt homelab-vault"]
    d["Dépôt homelab-docs"]
    t["Un troisième dépôt"]

    r1 --> v
    r2 --> d
    t -.->|"aucun runner éligible"| queued["runs « queued »<br/>indéfiniment"]

    classDef bad stroke-width:3px,stroke-dasharray: 5 5
    class queued bad

Los "runs" queued para siempre no son un error

Cuando no hay ningún runner disponible, las ejecuciones aparecen normalmente en la interfaz y permanecen queued. No hay mensajes, ni alertas, nada que indique que nadie las está recogiendo. Esto se interpreta como "el CI aún no está conectado".

El control que se divide en una solicitud:

curl -s -H "Authorization: token $TOKEN" \
  https://gitea.savethemall.eu/api/v1/repos/<owner>/<repo>/actions/runners \
  | jq '.runners[].name'
# tableau vide → ces jobs ne partiront jamais

Añadir un repositorio al CI, significa añadir un runner, o migrar un runner existente a un alcance más amplio — esta segunda opción detiene el CI que estaba sirviendo durante la operación, obligando a una ejecución "a frío".

El token de la instancia se solicita mediante POST, no GET:

POST /api/v1/repos/<owner>/<repo>/actions/runners/registration-token

Lo que contiene la imagen de las tareas — y no contiene

Las tareas runs-on: ubuntu-latest se ejecutan en node:20-bookworm.

Presente Ausente
git 2.39 pip
Python 3.11 venv
acceso a github.com y pypi.org cliente SSH

Debian entrega pip, venv y openssh-client por separado. Un flujo de trabajo que las asume falla tard, después del "checkout", con un mensaje que no indica que falta un paquete.

actions/setup-python no funciona en este entorno

::error::The version '3.12' with architecture 'x64' was not found
for this operating system.

La acción descarga los binarios publicados para las imágenes ubuntu-XX de GitHub. No existen para Debian bookworm. No se trata de un problema de red: el entorno de ejecución accede a github.com y pypi.org sin dificultad.

Instalar desde Debian en su lugar:

- name: Installer Python et les dépendances
  run: |
    apt-get update -qq
    apt-get install -y --no-install-recommends python3-venv python3-pip
    python3 -m venv /tmp/venv
    /tmp/venv/bin/pip install --no-cache-dir -r requirements.txt

Desplegar sin proporcionar un shell

Una clave de despliegue que abre un shell completo en el entorno de producción vale la pena el nombre de usuario de ese entorno. La forma utilizada aquí lo reduce a un único paso:

command="/opt/docker/<stack>/deploy-hook.sh",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty,restrict ssh-ed25519 AAAA…

Cualquier cosa que envíe el cliente, el servidor ejecuta este script y nada más. La verificación, en lugar de asumir:

ssh -i <clé> -p <port-ssh> <user>@vm-docker "cat /etc/shadow"
# doit afficher la sortie du déploiement, jamais le contenu du fichier

Corolario de diseño: el script debe realizar su propia verificación, ya que el cliente no puede enviar una segunda instrucción para controlar el resultado.

Dernière vérification de cette page : 2026-09-08