2026-09-17 13:30:36 +02:00
|
|
|
name: CI
|
|
|
|
|
|
|
|
|
|
on:
|
|
|
|
|
push:
|
|
|
|
|
branches: [main]
|
|
|
|
|
pull_request:
|
|
|
|
|
|
|
|
|
|
jobs:
|
|
|
|
|
build-and-test:
|
|
|
|
|
runs-on: ubuntu-latest
|
|
|
|
|
steps:
|
|
|
|
|
- uses: actions/checkout@v4
|
|
|
|
|
|
|
|
|
|
# rustup plutôt que le paquet apt de l'image : l'image du job
|
|
|
|
|
# (node:20-bookworm, Debian stable) embarque un rustc trop ancien
|
|
|
|
|
# pour ce code (async fn dans les traits, édition 2021 récente).
|
|
|
|
|
- name: Installer Rust
|
|
|
|
|
run: |
|
|
|
|
|
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
|
|
|
|
|
echo "$HOME/.cargo/bin" >> "$GITHUB_PATH"
|
|
|
|
|
|
|
|
|
|
- name: Dépendances système (sqlx/rustls)
|
|
|
|
|
run: apt-get update && apt-get install -y pkg-config libssl-dev build-essential
|
|
|
|
|
|
|
|
|
|
- name: cargo build (workspace)
|
|
|
|
|
run: cargo build --workspace
|
|
|
|
|
|
|
|
|
|
- name: cargo test (workspace)
|
|
|
|
|
run: cargo test --workspace
|
|
|
|
|
|
|
|
|
|
- name: npm build (app/)
|
|
|
|
|
working-directory: app
|
|
|
|
|
run: |
|
|
|
|
|
npm ci
|
|
|
|
|
npm run build
|
|
|
|
|
|
|
|
|
|
deploy:
|
|
|
|
|
needs: build-and-test
|
|
|
|
|
if: github.ref == 'refs/heads/main'
|
|
|
|
|
runs-on: ubuntu-latest
|
|
|
|
|
steps:
|
|
|
|
|
- uses: actions/checkout@v4
|
|
|
|
|
|
|
|
|
|
- name: Installer Rust
|
|
|
|
|
run: |
|
|
|
|
|
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
|
|
|
|
|
echo "$HOME/.cargo/bin" >> "$GITHUB_PATH"
|
|
|
|
|
|
|
|
|
|
- name: Dépendances système
|
|
|
|
|
run: apt-get update && apt-get install -y pkg-config libssl-dev build-essential openssh-client rsync
|
|
|
|
|
|
|
|
|
|
- name: Build release (workspace)
|
|
|
|
|
run: cargo build --release --workspace
|
|
|
|
|
|
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
|
|
|
- name: npm build (app/)
|
|
|
|
|
working-directory: app
|
|
|
|
|
run: |
|
|
|
|
|
npm ci
|
|
|
|
|
npm run build
|
|
|
|
|
|
2026-09-17 13:30:36 +02:00
|
|
|
# Identité de déploiement dédiée, sans privilège : `deploy` ne peut
|
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
|
|
|
# que déposer des fichiers dans /opt/deploy-staging et lancer les
|
|
|
|
|
# scripts sudo tripoli-deploy*.sh, qui installent exactement ce
|
|
|
|
|
# qui est attendu (binaire + redémarrage du service nommé, ou
|
|
|
|
|
# synchronisation du frontend statique) - rien de plus. Pas de clé
|
2026-09-17 13:30:36 +02:00
|
|
|
# root dans ce pipeline.
|
|
|
|
|
- name: Déployer tripoli-edge et tripoli-api
|
|
|
|
|
env:
|
|
|
|
|
DEPLOY_SSH_KEY: ${{ secrets.DEPLOY_SSH_KEY }}
|
|
|
|
|
DEPLOY_HOST: 65.109.142.188
|
|
|
|
|
run: |
|
|
|
|
|
mkdir -p ~/.ssh
|
|
|
|
|
echo "$DEPLOY_SSH_KEY" > ~/.ssh/deploy_key
|
|
|
|
|
chmod 600 ~/.ssh/deploy_key
|
|
|
|
|
ssh-keyscan -H "$DEPLOY_HOST" >> ~/.ssh/known_hosts 2>/dev/null
|
|
|
|
|
|
|
|
|
|
for service in tripoli-edge tripoli-api; do
|
|
|
|
|
scp -i ~/.ssh/deploy_key "target/release/$service" "deploy@$DEPLOY_HOST:/opt/deploy-staging/$service"
|
|
|
|
|
ssh -i ~/.ssh/deploy_key "deploy@$DEPLOY_HOST" sudo /usr/local/sbin/tripoli-deploy.sh "$service"
|
|
|
|
|
done
|
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
|
|
|
|
|
|
|
|
rsync -az -e "ssh -i ~/.ssh/deploy_key" --delete app/dist/ "deploy@$DEPLOY_HOST:/opt/deploy-staging/frontend/"
|
|
|
|
|
ssh -i ~/.ssh/deploy_key "deploy@$DEPLOY_HOST" sudo /usr/local/sbin/tripoli-deploy-frontend.sh
|