Files
ObsiGate/docs/DESKTOP_E2E_CHECKLIST.md
T
bruno 8ddee212e5
CI / lint (push) Successful in 1m7s
CI / security (push) Successful in 43s
CI / test (push) Successful in 2m12s
CI / build (push) Successful in 42s
CI / e2e (push) Successful in 10m43s
Desktop Build / build-windows (push) Canceled after 0s
Desktop Build / build-linux (push) Canceled after 0s
feat(desktop): manifeste de mise a jour latest.json + builds locaux signes (#77)
- scripts/updater_manifest.py : construit latest.json (version, pub_date, platforms Windows/Linux avec signature .sig et URLs des assets).

- publish_release.py : genere latest.json, upload des .sig + latest.json, rappel de commit.

- tauri.conf.json : endpoint updater -> raw/branch/main/desktop/latest.json.

- build-windows.bat / build-linux.sh : detection automatique de obsigate-updater.key (signature) ou repli non signe.

- .gitignore : ignore desktop/key/ ; tests/test_updater_manifest.py (8 tests).
2026-09-12 10:01:56 -04:00

7.9 KiB

ObsiGate Desktop — Protocole de tests E2E manuels

Rôle : valider les 6 scénarios de bout en bout du desktop Tauri (#77) qui ne peuvent pas être automatisés (interactions OS : installeur, tray, notifications, association de fichiers, auto-update, désinstallation). Statut : protocole documenté — à exécuter manuellement par un humain. Références : feature desktop-tauri · Roadmap · Build & releases


1. Prérequis

  • Un build release de l'application :
    • Windows : desktop\build-windows.bat → ObsiGate_x.y.z_x64.msi / -setup.exe
    • Linux : desktop/build-linux.sh → obsigate_x.y.z_amd64.deb / .AppImage
  • Une machine vierge ou un compte utilisateur propre (pas d'installation précédente) pour les tests d'installation/désinstallation.
  • Le mot de passe admin affiché au premier lancement (ou OBSIGATE_ADMIN_PASSWORD défini avant le lancement).
  • Accès en écriture aux logs : %APPDATA%\ObsiGate\logs\backend.log (Windows) ou ~/.config/obsigate/logs/backend.log (Linux).

2. Comment remplir ce protocole

Pour chaque test : noter la version testée (menu Aide → À propos), le commit du build, la date, puis cocher ✅ OK ou ❌ Échec et joindre les logs/ captures en cas d'échec. Ne cocher un test qu'après avoir observé le résultat attendu.

Test Version Commit Date Résultat
T1 — Installation ⬜
T2 — Tray icon ⬜
T3 — Notifications natives ⬜
T4 — Association .md ⬜
T5 — Auto-update ⬜
T6 — Désinstallation ⬜

T1 — Installation → premier lancement → ouverture d'un fichier

Objectif : l'installeur installe l'app et le premier lancement démarre le backend + affiche l'interface.

  1. Lancer l'installeur (.msi ou .deb/.AppImage).
  2. Installer dans le chemin par défaut → vérifier la création du raccourci (bureau / menu Démarrer / menu applications).
  3. Lancer ObsiGate depuis le raccourci.
  4. Observer l'écran de démarrage (« ObsiGate démarre… ») puis l'interface.
  5. Au premier lancement, cliquer « Choisir mon dossier » dans la bannière du wizard et sélectionner un dossier vault.
  6. Ouvrir un fichier .md depuis l'arborescence.

Résultat attendu :

  • Aucun terminal / console visible.
  • Le backend répond (http://127.0.0.1:17890/api/health → 200) en ~2 s.
  • Le fichier s'ouvre dans le viewer.
  • La bannière du wizard ne réapparaît pas au lancement suivant.

Échec si : écran blanc, backend non démarré, wizard qui revient à chaque lancement.


T2 — Tray icon → réduire → restaurer

Objectif : le tray fonctionne et contrôle la fenêtre.

  1. Vérifier la présence de l'icône ObsiGate dans la zone de notification.
  2. Clic gauche sur l'icône → la fenêtre se cache.
  3. Clic gauche à nouveau → la fenêtre réapparaît et prend le focus.
  4. Clic droit → menu (Ouvrir ObsiGate / À propos / Quitter).
  5. Fermer la fenêtre avec le X → elle se réduit dans le tray, le backend continue de tourner (l'icône reste).

Résultat attendu : toggle visible/caché immédiat, menu contextuel complet, fermeture par X = réduction (pas d'arrêt du backend).


T3 — Notifications natives (fichier modifié → popup OS)

Objectif : les notifications natives remplacent le push web.

  1. Activer les notifications dans les préférences (par vault si proposé).
  2. Modifier un fichier surveillé (édition externe dans le vault, ou édition in-app avec le watcher actif).
  3. Observer la notification du système d'exploitation.

Résultat attendu : popup OS affichant le nom du fichier/vault et l'action ; un clic ouvre le fichier concerné. La notification apparaît même si la fenêtre ObsiGate est réduite.

Note : sur Windows, vérifier que les notifications ne sont pas bloquées dans Paramètres → Système → Notifications.


T4 — Association .md → double-clic → ouvre dans ObsiGate

Objectif : l'association de fichiers ouvre l'app.

  1. Vérifier que .md est associé à « ObsiGate Markdown » (Windows : Paramètres → Applications par défaut ; Linux : xdg-mime query default text/markdown).
  2. Fermer complètement ObsiGate (tray → Quitter).
  3. Double-cliquer sur un fichier .md dans l'explorateur / gestionnaire de fichiers.
  4. Observer le lancement d'ObsiGate et l'ouverture du fichier.

Résultat attendu : ObsiGate démarre et ouvre le fichier (ou le vault contenant le fichier). Un second double-clic alors que l'app tourne focus la fenêtre existante (single-instance) au lieu de lancer un doublon.


T5 — Auto-update → nouvelle version → installation

Objectif : l'updater détecte et installe une nouvelle version.

  1. S'assurer qu'une release plus récente existe sur Gitea (avec les artefacts et le manifeste de mise à jour signé).
  2. Lancer la version N.
  3. Déclencher la vérification de mise à jour (menu ou au démarrage selon l'UI).
  4. Accepter la mise à jour → l'app télécharge, vérifie la signature et installe.
  5. Relancer → vérifier la version affichée (À propos).

Résultat attendu : détection de la version N+1, téléchargement, installation sans intervention manuelle, version mise à jour après redémarrage.

Prérequis bloquant : la release N+1 doit être publiée (binaires signés .sig + latest.json) et le fichier desktop/latest.json commité sur main (le manifeste est généré par scripts/publish_release.py, cf. §4).


T6 — Désinstallation propre

Objectif : la désinstallation ne laisse aucun processus ni résidu gênant.

  1. Fermer ObsiGate (tray → Quitter) pour éviter un processus orphelin.
  2. Désinstaller via le panneau de configuration (Windows) ou dpkg -r obsigate / supprimer l'AppImage (Linux).
  3. Vérifier qu'aucun processus obsigate-desktop / Python backend ne tourne encore.
  4. Vérifier les résidus : raccourcis supprimés, entrée « Applications par défaut » retirée.
  5. (Optionnel) Vérifier le comportement des données utilisateur (%APPDATA%\ObsiGate / ~/.config/obsigate) : conservées ou supprimées selon le choix documenté.

Résultat attendu : désinstallation sans erreur, aucun processus résiduel, aucun raccourci cassé.


3. Emplacements utiles

Élément Windows Linux
Config %APPDATA%\ObsiGate\config.json ~/.config/obsigate/config.json
Logs backend %APPDATA%\ObsiGate\logs\backend.log ~/.config/obsigate/logs/backend.log
Données (index, comptes) %APPDATA%\ObsiGate\data\ ~/.config/obsigate/data\

4. Signature de code & auto-update

  • Signature Windows (optionnelle, hors périmètre de ce protocole) : sans certificat, SmartScreen affiche un avertissement au premier lancement (Informations complémentaires → Exécuter quand même). Le script desktop/scripts/sign-windows.ps1 signe automatiquement si OBSIGATE_SIGN_CERT_PFX est défini ; sinon il est un no-op explicite. Alternatives détaillées dans le README desktop.
  • Signature de l'updater Tauri (gratuite, distincte de la signature Windows) : déjà configurée — pubkey dans desktop/tauri.conf.json, clé privée lue depuis desktop/obsigate-updater.key (gitignorée) ou TAURI_SIGNING_PRIVATE_KEY. Le manifeste latest.json est généré par scripts/publish_release.py puis commité sur main. Procédure : DEVELOPMENT_AND_RELEASES §2bis.

5. Clôture

Une fois les 6 tests exécutés et OK, reporter le résultat dans docs/features/desktop-tauri.md (section F) et mettre à jour le statut du #77 dans la Roadmap.