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:
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
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:
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