# CI/CD

Le brief demandait un `.gitlab-ci.yml`, mais ce dépôt vit sur **Forgejo**,
pas GitLab (voir le README racine) : l'équivalent réel est un workflow
**Forgejo Actions** (`.forgejo/workflows/ci.yml`), syntaxe compatible
GitHub Actions.

## Runner

Aucun runner Forgejo Actions n'existait sur ce serveur avant cette
phase. Déployé en systemd (`forgejo-runner.service`), conteneur
`code.forgejo.org/forgejo/runner:13.1`, socket Docker de l'hôte partagé
avec les conteneurs de job (`docker_host: "automount"` dans sa config)
plutôt qu'un `docker:dind` imbriqué et privilégié - plus léger sur une
machine à 3.7 Go déjà partagée, au prix d'une isolation plus faible
(un job de CI a accès au docker de l'hôte). Acceptable ici : instance
Forgejo mono-utilisateur, pas un service ouvert à des tiers.

## Déploiement : un compte dédié, pas root

Le pipeline ne se connecte jamais en root. Un utilisateur système
`deploy` existe uniquement pour :
1. recevoir le binaire compilé (`scp`) ou le build du frontend
   (`rsync`) dans `/opt/deploy-staging/` ;
2. lancer un des scripts sudo dédiés (voir `/etc/sudoers.d/deploy` sur
   le serveur), chacun figé sur une seule action :
   - `tripoli-deploy.sh <service>` - n'accepte que `tripoli-edge` ou
     `tripoli-api`, installe le binaire et redémarre exactement ce
     service ;
   - `tripoli-deploy-frontend.sh` - synchronise le build statique vers
     `/var/www/tripoli-cloud` (servi directement par Caddy, pas de
     redémarrage de service nécessaire).

   Rien d'autre n'est accessible via ce compte.

La clé privée correspondante est stockée comme secret Forgejo Actions
(`DEPLOY_SSH_KEY`), jamais dans ce dépôt.

## Workflow (`.forgejo/workflows/ci.yml`)

- `build-and-test` (toute PR et push) : installe Rust via rustup
  (l'image du job, `node:20-bookworm`, a un rustc système trop ancien
  pour ce code), `cargo build --workspace`, `cargo test --workspace`,
  puis `npm ci && npm run build` pour le frontend.
- `deploy` (uniquement sur `main`, après succès du job précédent) :
  build release + build frontend, puis dépôt/redémarrage de
  `tripoli-edge` et `tripoli-api`, et synchronisation du frontend
  statique - tout via le compte `deploy`.

`tripoli-netctl` et le labo `bird-lab` ne sont pas déployés par ce
pipeline : ce sont des outils de labo qu'on lance à la main, pas des
services qui tournent en continu.

## Frontend : plus de données simulées

Le frontend appelle désormais réellement `tripoli-api` (auth, upload
avec vraie progression XHR, photos/sauvegardes/notifications/espace
disque réels). Ce qui n'avait honnêtement rien de réel derrière dans la
maquette d'origine a été retiré plutôt que simulé : 2FA, clé de
récupération, accès partagés, albums, "appareils sauvegardés", chiffres
marketing inventés sur la page de connexion. Détails dans
`app/src/api/*.ts` (chaque module documente ce qu'il retire et
pourquoi).