Votre propre Git : Forgejo ou Gitea

Vous avez besoin de votre propre Git lorsque le code ne doit pas partir sur la plateforme d'un tiers, ou lorsque vous ne voulez aucune limite sur les dépôts privés et les minutes de build. Forgejo et Gitea sont deux projets étroitement liés (Forgejo est né de Gitea) ; les deux s'installent dans un seul conteneur et tournent sur une machine modeste.

Que choisir et combien de ressources

Il n'y a presque aucune différence au quotidien : l'interface, les tickets, les pull requests, les miroirs, les Actions pour les builds. Forgejo est développé par une communauté, Gitea par une entreprise. Choisissez Forgejo si l'indépendance du projet compte pour vous.

Pour deux ou trois personnes, VDS-1 suffit. Dès que vous ajoutez un runner pour les builds, prenez VDS-3 ou plus : les builds consomment du CPU et du disque, et la vitesse du disque est limitée par le tier.

Installation via Compose

services:
  forgejo:
    image: codeberg.org/forgejo/forgejo:11
    container_name: forgejo
    restart: unless-stopped
    environment:
      - USER_UID=1000
      - USER_GID=1000
    volumes:
      - ./data:/data
      - /etc/timezone:/etc/timezone:ro
    ports:
      - "3000:3000"
      - "2222:22"

docker compose up -d
docker compose logs -f forgejo

Ouvrez http://<machine-address>:3000 et passez par la configuration initiale. Le premier utilisateur créé devient l'administrateur.

Vous n'avez pas besoin de laisser le port 3000 ouvert vers l'extérieur. Fermez-le et placez un serveur web avec un certificat devant le service — vous obtenez ainsi HTTPS et vous ne montrez pas le panneau de configuration aux inconnus. Tant que la configuration n'est pas terminée, toute personne qui ouvre l'adresse peut créer l'administrateur en premier.

Accès SSH

Le port 22 à l'intérieur du conteneur est redirigé vers 2222, car 22 est occupé par le SSH du système. Dans les paramètres du dépôt, l'adresse ressemblera à ceci :

git clone ssh://git@example.com:2222/user/repo.git

Si vous voulez l'adresse habituelle git@example.com:user/repo.git sans port, laissez 2222 au conteneur et configurez la redirection sur l'hôte via le SSH du système, ou déplacez le SSH d'administration vers un autre port (voir protection des accès).

Builds

Les Actions sont exécutées par un runner séparé — le conteneur forgejo-runner, qui s'enregistre avec un token issu des paramètres de l'administrateur. Ne lui donnez accès au socket Docker que délibérément : cela équivaut à un accès root sur la machine. Pour les builds, il vaut mieux limiter le runner en mémoire et en CPU — voir limites de ressources.

Ce qu'il faut sauvegarder

Tout l'état est stocké dans le volume ./data : dépôts, base de données, pièces jointes, configuration. La sauvegarde se fait ainsi :

docker compose stop forgejo
restic -r <repository> backup ./data
docker compose start forgejo

Vous devez arrêter le service s'il utilise SQLite — sinon l'instantané de la base de données peut être incohérent. Avec PostgreSQL, pg_dump suffit sans arrêter le service. Pour plus de détails, voir ce qu'il faut sauvegarder exactement et Restic.

Erreurs courantes

• Oublier la taille des dépôts. Les builds de serveurs de jeu et les médias remplissent vite l'espace disque : 40 GB du tier d'entrée partent sans qu'on s'en aperçoive.
• Ne pas configurer l'e-mail. Sans cela, les invitations et les réinitialisations de mot de passe ne fonctionnent pas. Il est plus simple de connecter un SMTP externe que de configurer votre propre serveur mail.
• Mettre à jour sans sauvegarde. Changer de version majeure modifie le schéma de la base de données. D'abord une sauvegarde, puis docker compose pull — voir mise à jour des conteneurs.