CI mínima con hooks de Git y nq

• Es una configuración simple de CI que agrega un hook post-receive a un repositorio Git bare en un servidor personal para automatizar pruebas, builds y movimiento de archivos
• En comparación con las CI existentes, con configuraciones YAML complejas, ejecución lenta y self-hosting difícil, no se necesitaba aislamiento completo del build ni gestión de secretos
• Si las tareas se ejecutan directamente desde el hook, cuando fallan el push se rechaza o la finalización se demora, así que se procesan en segundo plano con la cola de tareas mínima nq
• El hook solo llama a nq y los logs se consultan con ssh server nqtail -a, lo que permite operarlo de forma rápida y simple
• Según sea necesario, se puede aislar el build con landdown·Podman y gestionar secretos con sops, o ampliar el flujo de desarrollo con parches de Git por email, git-shell y git http-backend

---

Configuración del hook post-receive y nq

• En un servidor personal, se crea el repositorio con ssh server git init --bare repo y se clona con git clone server:repo
• En el directorio hooks del repositorio bare, se coloca un hook post-receive en forma de script de shell para iniciar la CI cada vez que se hace push
• Ejecutar las tareas directamente desde el hook genera dos problemas
  • Si el script falla, el push se rechaza
  • Si la ejecución del script es lenta, también se demora la finalización del push
• Desde el hook se llama a la cola de tareas mínima nq para agregar las tareas a una cola en segundo plano
  • Los logs se consultan con ssh server nqtail -a
  • El proceso de configuración puede verse en un tutorial breve

Aislamiento y ampliación del flujo de desarrollo

• Para ejecutar builds en un sandbox, se puede usar landdown
• Se puede aislar el build del entorno del host con Podman o gestionar secretos con sops
• Para el desarrollo estilo bazaar, conviene una configuración que reciba parches de Git por email
• El desarrollo estilo cathedral puede configurarse con git-shell o git http-backend

[GN⁺]

Opiniones en Lobste.rs

• CI tiene al menos dos problemas
  El problema fácil es ejecutar make test cuando cambia el código, y el difícil es ejecutar make test en Linux, Windows y Mac

  • Linux es fácil y Windows es difícil, pero macOS es doloroso a otro nivel
  • Considero que la parte difícil de CI es el motor de ejecución de trabajos que también ayude a depurar cuando algo falla
    Como la experiencia de desarrollo y las funciones de depuración de los motores existentes siempre quedan en segundo plano, estoy creando un sistema de CI en https://ci.pico.sh. Tampoco me gustan los DSL, y los YAML encadenados jerárquicamente se sienten como si te fueran drenando lentamente la vida
  • Este enfoque resuelve el problema fácil, y con QEMU podría soportar la familia BSD y con Docker extenderse a varias distribuciones, pero para más que eso parece hacer falta una herramienta más completa

• Una vez construí algo así sobre gitolite y lo pasé a Temporal para controlar el proceso de build sin limitaciones
  Ante una falla de ejecución también se puede rechazar el push, pero normalmente prefiero dejar pasar el hook y manejar la falla por separado; la configuración también fue simple y divertida

  • Me gustan especialmente las herramientas de control de acceso de gitolite, y también es excelente la forma en que permite crear un repositorio nuevo haciendo push a un repositorio que no existe

• Otro CI mínimo centrado en ejecutar scripts de shell es laminar CI, que también ofrece una UI web

• Hace mucho, en un entorno corporativo exclusivo de Windows, usamos una Mac mini como servidor de CI local para todo el equipo y construíamos apps de iOS; fue uno de mis primeros intentos de aprovechar Git

• Lo encontré en https://mccd.space/git/; parece que usa un fork de stagit
  Hasta hace unos meses mantenía Forgejo y Woodpecker, pero eliminé todo porque la mayoría de las funciones no me hacían falta y estaba buscando una configuración más liviana parecida a esta. Como mi siguiente pendiente era CI, llegó en buen momento, y estoy considerando si espejar en SourceHut una pequeña biblioteca que publicaré pronto

  • Hice un fork de stagit, agregué un correo de contacto y una barra de navegación, añadí IDs para cambios de CSS y eliminé información innecesaria
    Los repositorios se publican en la web en modo solo lectura con git-daemon, y dejé documentada toda la configuración aquí

• Con este artículo conocí nq por primera vez, pero probablemente usaría systemd-run
  Como uso Nix en casi todos mis runners, si expongo el resultado de nix flake check como métricas y logs OTLP, creo que podría resolver los requisitos de CI con el sistema de monitoreo

• Me gusta una configuración de plataforma de desarrollo self-hosted tan simple como esta
  Para CI se puede configurar y usar fácilmente bubblewrap, un sistema de contenedores ligero y simple. Sin embargo, si se usa nq, parece imposible rechazar el push cuando falla CI; me da curiosidad cómo lo manejan

  • También hay una herramienta auxiliar que usa Landlock para restringir scripts, y creo que su uso es un poco más simple
    Si se necesita más aislamiento, se pueden agregar Podman, Docker o bubblewrap. No rechazo los pushes cuando falla CI por la misma razón por la que no pongo hooks pre-commit que ejecuten tests: a veces hay que commitear o pushear trabajo roto, y el push puede volverse muy lento. Si se necesita rechazarlo, se puede ejecutar CI de forma síncrona sin nq y bloquear el push cuando el código de salida no sea 0
    O bien, las ramas que no sean main pueden ejecutarse con nq y solo la rama main de forma síncrona

• Parece que el enlace de landdown está roto

  • Lo arreglaré cuando llegue a casa; la URL correcta es https://mccd.space/git/landdown/file/README.html