Un CI minimaliste avec des hooks Git et nq

• Une configuration CI simple qui ajoute un hook post-receive au dépôt Git bare d’un serveur personnel afin d’automatiser les tests, les builds et le déplacement de fichiers
• Les CI existants imposaient des configurations YAML complexes, des exécutions lentes et un auto-hébergement difficile, alors qu’il n’y avait pas besoin d’une isolation complète des builds ni d’une gestion des secrets
• Exécuter les tâches directement dans le hook peut refuser le push en cas d’échec ou retarder sa finalisation ; le traitement est donc délégué en arrière-plan à la file de tâches minimaliste nq
• Le hook appelle seulement nq, et les logs se consultent avec ssh server nqtail -a, pour une exploitation rapide et simple
• Selon les besoins, il est possible d’isoler les builds avec landdown·Podman, de gérer les secrets avec sops, ou d’étendre le mode de développement avec des patchs Git par e-mail, git-shell ou git http-backend

---

Configuration du hook post-receive et de nq

• Sur un serveur personnel, créer un dépôt avec ssh server git init --bare repo, puis le cloner avec git clone server:repo
• Placer un hook post-receive sous forme de script shell dans le répertoire hooks du dépôt bare afin de lancer le CI à chaque push
• Exécuter les tâches directement dans le hook pose deux problèmes
  • Si le script échoue, le push est refusé
  • Si l’exécution du script est lente, la finalisation du push est retardée d’autant
• Dans le hook, appeler la file de tâches minimaliste nq pour ajouter la tâche à une file en arrière-plan
  • Les logs se consultent avec ssh server nqtail -a
  • Le processus de configuration est décrit dans un court tutoriel

Isolation et extension du mode de développement

• Pour exécuter les builds dans un bac à sable, il est possible d’utiliser landdown
• Podman permet d’isoler les builds de l’environnement hôte, et sops de gérer les secrets
• Pour un développement de type bazaar, une configuration recevant des patchs Git par e-mail est adaptée
• Un développement de type cathedral peut être configuré avec git-shell ou git http-backend

[GN⁺]

Avis sur Lobste.rs

• Il y a au moins deux problèmes en CI
  Le problème facile, c’est d’exécuter make test quand le code change, et le problème difficile, c’est d’exécuter make test sur Linux, Windows et Mac

  • Linux est facile et Windows est difficile, mais macOS est carrément pénible
  • La partie difficile en CI, c’est selon moi le moteur d’exécution des tâches qui doit aussi aider au débogage en cas d’échec
    Je suis frustré que l’expérience développeur et les fonctions de débogage des moteurs existants passent toujours au second plan, donc je construis un système de CI sur https://ci.pico.sh. Je n’aime pas non plus les DSL, et le YAML hiérarchique enchaîné donne l’impression d’aspirer lentement toute énergie vitale
  • Cette approche résout le problème facile, et on pourrait l’étendre aux systèmes BSD avec QEMU et à plusieurs distributions avec Docker, mais au-delà il semble falloir un outil plus complet

• J’ai déjà construit quelque chose comme ça sur gitolite et je le transmettais à Temporal pour contrôler le processus de build sans restriction
  On peut rejeter un push si l’exécution échoue, mais en général je laisse le hook passer puis je gère l’échec séparément, et la configuration était simple et amusante

  • J’aime particulièrement les outils de contrôle d’accès de gitolite, et la manière de créer un nouveau dépôt en poussant vers un dépôt inexistant est excellente

• Il y a aussi laminar CI comme autre CI minimale centrée sur l’exécution de scripts shell, avec en plus une interface web

• Il y a longtemps, dans un environnement d’entreprise Windows uniquement, on utilisait un Mac mini comme serveur de CI local partagé par toute l’équipe pour compiler une app iOS, et c’était l’un des premiers usages de Git qu’on avait tentés

• J’ai trouvé ça via https://mccd.space/git/ , et il semble utiliser un fork de stagit
  Jusqu’à il y a quelques mois, j’exploitais Forgejo et Woodpecker, mais comme la plupart des fonctions ne m’étaient pas utiles, j’ai tout retiré et je cherchais une configuration plus légère du même genre. Ma prochaine tâche étant la CI, ça tombe à pic, et je me demande si je vais mirrorer une petite bibliothèque que je publierai bientôt sur SourceHut

  • J’ai forké stagit pour ajouter une adresse e-mail de contact et une barre de navigation, inséré des ID pour modifier le CSS et retiré les informations inutiles
    Le dépôt est exposé en lecture seule sur le web via git-daemon, et toute la procédure de mise en place est documentée ici

• J’ai découvert nq grâce à cet article, mais j’utiliserai sans doute plutôt systemd-run
  J’utilise Nix pour presque tous mes runners, donc si j’expose les résultats de nix flake check comme métriques et logs OTLP, j’aurai peut-être une solution aux besoins de CI via le système de monitoring

• J’aime ce genre de plateforme de développement auto-hébergée, simple comme tout
  Pour la CI, on peut facilement configurer et utiliser bubblewrap, un système de conteneurs léger et simple. En revanche, avec nq, il ne semble pas possible de rejeter un push en cas d’échec de la CI ; je me demande comment c’est géré

  • Il existe aussi un outil auxiliaire qui utilise Landlock pour restreindre les scripts, et son usage me paraît un peu plus simple
    Si davantage d’isolation est nécessaire, on peut ajouter Podman, Docker ou bubblewrap. Je ne rejette pas les push en cas d’échec de la CI, pour la même raison qu’on ne met pas de hook pre-commit exécutant les tests : il faut parfois quand même pouvoir commit ou push du travail cassé, et les push peuvent devenir très lents. Si le rejet est nécessaire, il suffit d’exécuter la CI de façon synchrone sans nq et de bloquer le push si le code de sortie n’est pas 0
    Ou bien on peut exécuter avec nq sur les branches autres que main et n’exécuter de façon synchrone que sur la branche main

• Le lien vers landdown semble cassé

  • Je le corrigerai en rentrant chez moi ; la bonne adresse est https://mccd.space/git/landdown/file/README.html