diff --git a/capsule/content/gemlog/2022-12-11-un-peu-de-CI.gmi b/capsule/content/gemlog/2022-12-11-un-peu-de-CI.gmi
new file mode 100644
index 0000000..f979ce1
--- /dev/null
+++ b/capsule/content/gemlog/2022-12-11-un-peu-de-CI.gmi
@@ -0,0 +1,34 @@
+---
+title: un peu de CI
+date: 2022-12-11
+params:
+  tags: gitea,drone
+---
+
+Je n'ai pas trop mis à jour cette capsule ces derniers temps... Je me rends compte que malgré la bonne volonté initiale, j'ai toujours du mal à produire du contenu régulièrement. Non pas que je n'ai rien à dire mais plus en raison d'un mélange de manque de motivation et d'un besoin étrange de rotation d'intérêts/loisirs. Je vais profiter de ce petit billet pour évoquer quelques avancées sur mon auto-hébergement git avec Gitea, mais également DroneCI [1].
+
+Comme je l'indiquais précédemment, je n'avais pas prévu de m'auto-héberger pour mes dépôts git. Cependant, il semble que la fin de vie de framagit arrive, certes pas tout de suite mais mieux vaut anticiper un peu. De plus, je jongle régulièrement avec gitlab.com car framagit ne propose pas de registry. C'est une bonne opportunité pour tout reprendre de mon côté.
+
+Dans la suite de la migration, j'ai commencé à reprendre mes dépôts git pour les importer quand cela en vallait le coup. A paramétrer mes outils pour que ceux-ci utilisent mes nouveaux dépôts (tt-rss, wikijs, gemini...) mais il a été rapidement nécessaire pour moi d'utiliser la fonctionnalité registry docker de Gitea. Et pour cela, il est nécessaire d'avoir une CI connectée à Gitea. Il existe plusieurs possibilités: Jenkins, CircleCI, DroneCI... Pour ma part, j'ai choisit la CI que l'on retrouve le plus souvent avec Gitea : DroneCI.
+
+DoneCI se comporte un peu comme les runners de GitLab. Il est cependant nécessaire d'installer deux composants distincts: un serveur et un runner.
+
+Petite vigilance sur la vie-privée, étrangement une fonctionnalité Datadog est activée par défaut et pas vraiment documentée. Je l'ai donc désactivée avec la variable:
+
+```
+DRONE_DATADOG_ENABLED: "false"
+```
+
+Le runner peut être de différent type, j'ai choisit quelque chose de proche à celui qu'on utilise sur gitlab, un runner docker. Au détail près que je ne dispose pas de docker sur mon infrastructure mais uniquement podman. J'ai cru que j'allais être coincé mais il s'avère que la tâche a été simple.
+
+
+En effet podman propose un service `podman.socket` que l'utilisateur peut activer. Il met à disposition une socket compatible avec celle de docker. De ce fait, on peut facilement faire croire à Drone qu'il dispose d'un démon docker. Cela me permet donc de continuer à faire du container avec un utilisateur sans privilège.
+
+Une fois le serveur installé et configuré avec ses identifiants oauth2, il ne reste plus qu'à associer le runner de type "docker" à celui-ci et le tour est presque joué. Peut-être qu'avec la socket podman j'aurais pu tenter le "docker-in-docker" (dind) mais jouons le "sans docker" jusqu'au bout ! J'ai donc implémenter la construction d'image avec kaniko en suivant la procédure fournie sur le site de gitlab [2].
+
+Bien sûr DroneCI ne fait pas que construire des images docker et permet de faire de la CI (Continuous Integration) et potentiellement aussi de la CD (Continuous Delivery) mais pour l'instant je n'ai pas vraiment de cas d'usage si ce n'est un peu de CI pour mon bot LichessInfo que je n'ai pas encore rappatrié.
+
+Par contre j'ai constaté que la performance de la registry docker était moyenne, il se peut que j'ai quelques optimisations à faire sur HAproxy ou directement dans la configuration de Gitea.
+
+=> https://drone.io [1] site de DroneCI
+=> https://docs.gitlab.com/ee/ci/docker/using_kaniko.html [2] usage de kanico pour construire une image