Troisième épisode, et cette fois on part sur une stack DevOps complète : héberger son code, faire tourner sa CI, et publier sa doc. Trois briques qui, ensemble, remplacent sans trop forcer un combo GitHub + GitHub Actions + GitHub Pages, sauf que là tout tourne chez toi.
Forgejo — ton propre GitHub, sans les dérives
Forgejo, c'est un fork de Gitea né fin 2022 et devenu hard fork début 2024, principalement pour garantir que le projet reste gouverné par sa communauté (via l'association Codeberg e.V.) plutôt que par les intérêts commerciaux d'une entreprise. Concrètement, pour l'usage quotidien, ça reste ce qu'on attend d'un forge : dépôts Git, issues, pull requests, wiki, package registry, tout ça dans une interface propre et légère en ressources — Go et une base SQLite ou Postgres suffisent largement, pas besoin d'un serveur monstrueux comme pour certaines alternatives plus lourdes.
Petit aparté que je trouve vraiment intéressant : Forgejo bosse activement sur ForgeFed, un protocole de fédération basé sur ActivityPub (le même protocole qui fait tourner Mastodon). L'idée, c'est de faire pour les forges de code ce que le fediverse a fait pour les réseaux sociaux : permettre à des instances Forgejo différentes de communiquer entre elles, ouvrir une issue sur un dépôt hébergé ailleurs sans avoir à s'y créer un compte, suivre un projet depuis ton instance perso comme tu suivrais un compte Mastodon. Pour l'instant c'est encore expérimental — la fédération des étoiles sur les dépôts est en place, mais le reste (pull requests, issues fédérées) est encore en chantier et le projet prévient lui-même que ça peut casser sans préavis. Mais la direction est claire : sortir du modèle où GitHub est le point de passage obligé de tout l'open source, un peu comme Mastodon a cassé le monopole de Twitter sur la conversation publique.
Woodpecker CI — une CI qui reste simple
Woodpecker, c'est le moteur de CI/CD qui vient naturellement compléter Forgejo (même s'il fonctionne aussi très bien avec GitHub, GitLab ou Gitea). Chaque pipeline est défini dans un fichier YAML à la racine du repo, chaque étape tourne dans son propre conteneur Docker, et c'est à peu près tout ce qu'il y a à savoir pour démarrer. Pas de DSL propriétaire à apprendre, pas d'interface à tiroirs avec cinquante options cachées — tu écris tes steps comme des commandes shell dans des conteneurs, et ça roule.
C'est un fork de Drone CI, né après que Drone soit passé sous une licence plus restrictive côté fonctionnalités entreprise. Woodpecker a repris le flambeau en gardant tout ouvert. L'avantage par rapport à des usines à gaz comme Jenkins, c'est justement cette simplicité : pas de plugins Java à gérer, pas de configuration XML infernale. L'inconvénient, c'est que si t'as besoin de pipelines super complexes avec des dépendances croisées entre projets, tu vas sentir les limites plus vite qu'avec un GitLab CI complet. Pour une stack homelab classique — build d'image, tests, déploiement — ça fait le taf sans prise de tête.
Zensical — la doc statique nouvelle génération
Celui-là est tout frais, sorti par l'équipe derrière Material for MkDocs (l'un des thèmes de documentation les plus utilisés dans l'écosystème Python). Zensical, c'est leur nouvelle génération de générateur de site statique pour la doc : tu écris en Markdown, tu lances un build, et t'obtiens un site complet avec recherche intégrée, coloration syntaxique, admonitions, et un rendu visuel soigné — sans avoir à toucher à une ligne de HTML ou CSS.
Ce qui change par rapport à MkDocs (qui commence à montrer son âge, plus maintenu depuis un moment côté version 1.x), c'est que Zensical est écrit en Rust et Python, avec un vrai effort sur la vitesse de build et les retours immédiats en local — fini d'attendre dix secondes pour voir une modif d'une ligne. La configuration passe par un fichier TOML plutôt que YAML, ce qui évite pas mal de pièges classiques (les fameux no ou off interprétés comme des booléens au lieu de strings). Le projet reste résolument open source malgré un modèle de financement à la MkDocs Material (sponsors, fonctionnalités premium via "Zensical Spark" pour soutenir l'équipe).
Pour un usage self-hosted, c'est parfait pour publier automatiquement la doc d'un projet depuis ta CI : un pipeline Woodpecker qui build avec Zensical à chaque push, et hop, ta doc est à jour sans intervention manuelle.
Le trio complet
Ensemble, ces trois outils couvrent tout le cycle de vie du code : Forgejo héberge, Woodpecker teste et déploie, Zensical documente. Rien ne sort de chez toi, et si un jour Forgejo arrive à maturité sur la fédération, tu pourras même interagir avec d'autres forges sans quitter la tienne — une vraie alternative au modèle centralisé qu'impose GitHub aujourd'hui.
Liens utiles
Forgejo : https://forgejo.org/
ForgeFed : https://forgefed.org/
Woodpecker CI : https://woodpecker-ci.org/
Zensical : https://zensical.org/