Homelab 8 : votre propre forge de code, où rien n'arrive sur main sans contrôle vert
Forgejo est une forge de code open source, un GitHub auto-hébergé : dépôts, pull requests, tickets, et une CI (Forgejo Actions) qui parle le même format de workflows. À la maison, elle devient plus qu'une sauvegarde de votre code : c'est l'endroit où des agents IA proposent des changements, et où une machine, et non la bonne volonté, décide de ce qui arrive sur main.
1. La forge
Forgejo tourne en conteneur à côté d'une base PostgreSQL. Suivez la page d'installation Docker officielle, épinglez la version, et publiez l'interface web par votre proxy HTTPS (Homelab 2).
Git en SSH a besoin de son propre port, distinct du web. Le proxy HTTPS ne transporte que l'interface web : utilisez HTTPS pour les clones à distance, ou rejoignez le port SSH par votre réseau privé (Homelab 6). Ne l'ouvrez pas sur Internet.
2. Le runner
Les jobs de CI tournent sur un runner, un programme à part, idéalement sur une autre VM, qui lance chaque job dans un conteneur neuf. Créez-le dans Administration du site → Actions → Runners → Create new runner, puis suivez la page d'enregistrement de la documentation de votre version.
Le runner annonce des labels ; un workflow en demande un avec runs-on. Dans le fichier de configuration du runner, sous runner → labels, associez un label à une image :
ubuntu-latest:docker://node:lts3. La règle qui change tout
Dans les réglages du dépôt, protégez main : pas de push direct, et le contrôle de CI est exigé avant toute fusion. Dès lors, un humain comme un agent IA propose un changement par pull request ; il fusionne quand les tests passent, et seulement alors. Chaque dépôt de notre forge naît d'un modèle qui arme cette protection à la création : aucun ne peut exister sans elle.
Pièges que nous avons payés
Un job dont le runs-on ne correspond à aucun label attend pour toujours, sans erreur. Si un run reste « waiting », comparez d'abord son label à celui du runner.
Ne lancez pas les jobs dans une image slim : les actions JavaScript comme checkout ont besoin de node dans le conteneur du job, et le job meurt avant sa première étape.
Référencez les actions par leur URL complète, par exemple https://data.forgejo.org/actions/checkout@v4 : les noms courts façon GitHub ne sont pas résolus de la même manière.
Quand la CI est rouge, lisez le journal de la forge avant de reproduire quoi que ce soit. Un jour, une reproduction locale est sortie verte sur du code vraiment cassé ; le journal citait d'emblée les quatre assertions en échec.
Une CI verte ne prouve rien si les tests n'exécutent jamais le code. Cassez le code exprès (une mutation) et vérifiez qu'un test passe au rouge. Nous avons fusionné un en-tête de requête construit et jamais envoyé, sous une CI verte.
Sources
Utile ? Dites-nous ce qu'il faut mesurer ensuite.