OneDev sur VPS : Git, CI/CD et Kanban self-hostés

Gitea est excellent pour héberger du code : il est léger, rapide et couvre tous les besoins d'une forge Git classique. Mais dès qu'on veut du CI/CD, il faut installer un runner séparé (gitea/act_runner), le configurer, surveiller ses jobs et l'exposer au réseau. OneDev fait tout ça par défaut : quand vous poussez un .onedev-buildspec.yml, un pipeline se met en file d'attente et s'exécute dans un conteneur Docker sur le même VPS — aucun service supplémentaire à configurer.

Cette intégration s'étend aux issues et aux tableaux Kanban : au lieu de gérer un projet dans une troisième application, les cartes Kanban d'OneDev se déplacent automatiquement quand une branche est créée, une pull request ouverte ou un commit mergé. Le résultat est un poste de développement cohérent, sans jonglage entre onglets.

OneDev tourne comme deux conteneurs Docker : 1dev/server (l'application Java) et postgres:14 (la base de données). L'application écoute sur le port 6610 ; ServOrbit place un vhost nginx devant elle et gère le TLS. Tout passe par le même domaine : l'interface web, les clones Git en HTTPS, les webhooks CI et le registre de paquets.

L'image 1dev/server embarque également un agent de build local. Quand un pipeline démarre, il lance un conteneur Docker pour chaque étape de build — c'est pourquoi la socket Docker (/var/run/docker.sock) est montée dans le conteneur OneDev. Cette conception est standard pour les plateformes CI auto-hébergées (Jenkins, Drone, Woodpecker l'utilisent aussi) et permet de configurer des runners distants si vous avez besoin de parallélisme ou d'isolation matérielle.

La base de données PostgreSQL stocke les dépôts (sous forme de dépôts Git bare dans /opt/onedev), les issues, les membres, les jobs CI et la configuration. Un seul volume Docker suffit pour tout sauvegarder.

La RAM consommée au démarrage est d'environ 512 Mo pour un VPS sans utilisateurs actifs. La JVM HotSpot optimise la mémoire au fil des exécutions, mais il est prudent de commencer avec 2 Go pour laisser de la marge aux builds Docker concurrents. Un VPS de 4 Go de RAM est suffisant pour une équipe de dix développeurs avec deux ou trois jobs CI parallèles.

OneDev utilise son propre format YAML de pipeline, différent de GitHub Actions ou GitLab CI. La structure de base comprend des jobs avec des steps. Chaque step peut utiliser une image Docker, exécuter un script, publier un artefact ou envoyer une notification.

Exemple minimal pour un projet Node.js :

version: 36
jobs:
- name: Build
  steps:
  - !CheckoutStep
    name: checkout
    cloneCredential: !DefaultCredential {}
  - !CommandStep
    name: install and test
    image: node:20-alpine
    commands:
    - npm ci
    - npm test
  triggers:
  - !BranchUpdateTrigger {}

Le concepteur visuel de pipelines génère ce YAML graphiquement : vous ajoutez des étapes depuis l'interface, configurez les images Docker, les variables d'environnement et les déclencheurs, et OneDev écrit le fichier pour vous. C'est utile pour démarrer, même si la plupart des équipes finissent par éditer le YAML directement pour un contrôle plus fin.

Les !CommandStep prennent en charge les matrices de build (matrix), les artifacts entre étapes (artifactRequirements), et les conditions de déclenchement (branchUpdateTrigger, pullRequestTrigger, tagCreateTrigger). Les pipelines peuvent aussi être planifiés via scheduleTrigger pour des tâches nocturnes — migrations de base de données, génération de rapports, nettoyage de branches. Un tableau de bord dédié affiche l'état de tous les jobs en temps réel et conserve l'historique complet des exécutions avec les logs horodatés.

OneDev stocke tout dans deux volumes Docker : onedev_data (dépôts Git, config, jobs) et onedev_db (base PostgreSQL). Une sauvegarde complète consiste à archiver ces deux volumes.

docker run --rm \
  -v onedev_data:/data \
  -v /backup:/backup \
  alpine tar czf /backup/onedev-data.tar.gz /data

docker run --rm \
  -v onedev_db:/pgdata \
  -v /backup:/backup \
  alpine tar czf /backup/onedev-db.tar.gz /pgdata

Alternativement, la commande pg_dump depuis l'intérieur du conteneur PostgreSQL produit un dump SQL plus portable. Les dépôts Git dans onedev_data sont des dépôts bare standard : un git clone --mirror vers un stockage externe est une autre stratégie valide pour les dépôts seuls.

OneDev peut aussi configurer des sauvegardes automatiques vers un stockage objet compatible S3 depuis Site Administration → Settings → Backup Settings. Le volume onedev_data contient à la fois les dépôts Git et les fichiers de configuration d'OneDev — il est donc plus volumineux que le volume d'une base SQL seule. Estimez 1 Go par dépôt actif pour la fenêtre de rétention de builds CI (logs, artefacts) et prévoyez un stockage objet si vous accumulez beaucoup d'artefacts de build.