2026-09-17 13:30:36 +02:00
|
|
|
# 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 :
|
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
|
|
|
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.
|
2026-09-17 13:30:36 +02:00
|
|
|
|
|
|
|
|
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) :
|
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
|
|
|
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`.
|
2026-09-17 13:30:36 +02:00
|
|
|
|
|
|
|
|
`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 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
|
|
|
|
|
|
|
|
## 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).
|