- 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).
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
- Windows :
- 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_PASSWORDdé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.
- Lancer l'installeur (
.msiou.deb/.AppImage). - Installer dans le chemin par défaut → vérifier la création du raccourci (bureau / menu Démarrer / menu applications).
- Lancer ObsiGate depuis le raccourci.
- Observer l'écran de démarrage (« ObsiGate démarre… ») puis l'interface.
- Au premier lancement, cliquer « Choisir mon dossier » dans la bannière du wizard et sélectionner un dossier vault.
- Ouvrir un fichier
.mddepuis 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.
- Vérifier la présence de l'icône ObsiGate dans la zone de notification.
- Clic gauche sur l'icône → la fenêtre se cache.
- Clic gauche à nouveau → la fenêtre réapparaît et prend le focus.
- Clic droit → menu (Ouvrir ObsiGate / À propos / Quitter).
- 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.
- Activer les notifications dans les préférences (par vault si proposé).
- Modifier un fichier surveillé (édition externe dans le vault, ou édition in-app avec le watcher actif).
- 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.
- Vérifier que
.mdest associé à « ObsiGate Markdown » (Windows : Paramètres → Applications par défaut ; Linux :xdg-mime query default text/markdown). - Fermer complètement ObsiGate (tray → Quitter).
- Double-cliquer sur un fichier
.mddans l'explorateur / gestionnaire de fichiers. - 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.
- S'assurer qu'une release plus récente existe sur Gitea (avec les artefacts et le manifeste de mise à jour signé).
- Lancer la version N.
- Déclencher la vérification de mise à jour (menu ou au démarrage selon l'UI).
- Accepter la mise à jour → l'app télécharge, vérifie la signature et installe.
- 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.
- Fermer ObsiGate (tray → Quitter) pour éviter un processus orphelin.
- Désinstaller via le panneau de configuration (Windows) ou
dpkg -r obsigate/ supprimer l'AppImage (Linux). - Vérifier qu'aucun processus
obsigate-desktop/ Python backend ne tourne encore. - Vérifier les résidus : raccourcis supprimés, entrée « Applications par défaut » retirée.
- (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.ps1signe automatiquement siOBSIGATE_SIGN_CERT_PFXest 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 —
pubkeydansdesktop/tauri.conf.json, clé privée lue depuisdesktop/obsigate-updater.key(gitignorée) ouTAURI_SIGNING_PRIVATE_KEY. Le manifestelatest.jsonest généré parscripts/publish_release.pypuis commité surmain. 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.