adam/tripoli.cloud
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
tripoli.cloud/ci
History
Adam Belkacemi a639b705a6
All checks were successful
CI / build-and-test (push) Successful in 2m14s
Details
CI / deploy (push) Successful in 3m17s
Details
Frontend et backend entièrement réels : plus aucune donnée simulée 
À la demande explicite de l'utilisateur après avoir constaté que
tripoli.cloud affichait un 404 vide (le frontend n'avait jamais été
déployé) : déploiement du frontend, puis remplacement complet des
mocks par de vraies données, des deux côtés.

Backend (tripoli-api) :
- users.name, files.category (file/photo/backup), table notifications
  (migration 0002).
- POST /api/auth/guest : compte invité réel et réutilisé
  (invite@tripoli.local), pas une identité simulée côté frontend.
- GET /api/files?category=... , GET /api/notifications (+ read-all/
  {id}/read), GET /api/storage (used_bytes réel, available_bytes via
  statvfs - jamais un quota inventé).
- Notifications émises réellement sur upload/suppression.

Frontend (app/) :
- src/api/*.ts appellent réellement tripoli-api (plus de mockFetch).
- Upload réel (XHR, vraie progression), suppression avec bouton dédié,
  vraies miniatures photo (<img src="/api/files/:id">).
- Session restaurée au chargement (GET /api/auth/me), logout réel.
- Retiré plutôt que simulé : 2FA, clé de récupération, accès partagés,
  albums, dossiers, "4 appareils sauvegardés", chiffres marketing et
  claim AES-256 côté client sur la page de connexion (jamais vrai -
  remplacé par le vrai : HTTPS + Argon2).

Déploiement :
- Frontend construit et déployé sur le serveur (le build local échouait
  spécifiquement sur cette machine - rolldown/esbuild natif ne répondait
  plus, cause non résolue ; contourné en buildant sur le serveur, comme
  déjà fait pour les crates Rust).
- Caddy : /var/www/tripoli-cloud servi en statique pour tripoli.cloud,
  /api/*, /healthz, /metrics toujours proxyés vers tripoli-edge.
- Pipeline CI étendu : le job deploy construit et déploie maintenant
  aussi le frontend, via un script sudo dédié supplémentaire
  (tripoli-deploy-frontend.sh) sur le compte deploy sans privilège.
- Vérifié en navigateur réel (Chrome) : inscription, connexion, invité,
  upload avec progression, photos, sauvegardes, notifications,
  suppression, déconnexion - tous testés en conditions réelles.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-17 18:19:51 +02:00
..
forgejo-runner.service CI/CD : Forgejo Actions (pas GitLab - le dépôt vit sur Forgejo) 2026-09-17 13:30:36 +02:00
README.md Frontend et backend entièrement réels : plus aucune donnée simulée 2026-09-17 18:19:51 +02:00

README.md

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).