Mises à jour automatiques
Comment Oleafly construit, signe, vérifie et publie son flux de mise à jour multiplateforme.
Oleafly utilise le greffon de mise à jour de Tauri. Au lancement, l’application vérifie la dernière version GitHub et ouvre sa propre fenêtre de mise à jour quand une version plus récente est disponible. Les utilisateurs peuvent aussi lancer la vérification depuis le menu de l’application ou À propos → Rechercher des mises à jour.
Flux de versions
Section intitulée « Flux de versions »Chaque build de plateforme crée des artefacts de mise à jour signés et un fragment latest.json. Le workflow de publication garde ces fragments séparés jusqu’à ce que les quatre builds soient terminés, puis fusionne les entrées propres à chaque cible en un manifeste canonique.
Le manifeste final doit contenir des entrées pour macOS Apple Silicon, Windows x64, Linux x64 et Linux ARM64. Il reste attaché à une version brouillon jusqu’à ce qu’un mainteneur exécute le workflow de publication protégé. Les applications installées ne voient pas le brouillon.
L’application télécharge latest.json depuis GitHub Releases. Avant l’installation, Tauri vérifie la signature de mise à jour auprès de la clé publique intégrée dans src-tauri/tauri.conf.json. Les artefacts manquants, non signés ou altérés sont rejetés.
Les notes de version proviennent de la section correspondante dans CHANGELOG.md. Le workflow extrait cette section et l’utilise à la fois pour le corps de la version GitHub et pour la fenêtre de mise à jour.
Clés de signature
Section intitulée « Clés de signature »La clé publique de mise à jour est versionnée dans src-tauri/tauri.conf.json. La clé privée n’a sa place que dans les secrets GitHub Actions :
TAURI_SIGNING_PRIVATE_KEYTAURI_SIGNING_PRIVATE_KEY_PASSWORD
Ne versionnez jamais la clé privée. Si elle est exposée, générez une nouvelle paire, mettez à jour le secret du dépôt et remplacez la clé publique intégrée. Les installations existantes font confiance à leur clé intégrée : une rotation exige donc un chemin de mise à jour manuelle planifié.
La signature du système d’exploitation est distincte de la signature de mise à jour. Les builds macOS utilisent la signature de code Apple et la notarisation quand les secrets de publication sont présents. Les builds Windows utilisent Azure Artifact Signing quand ses identifiants sont présents.
Échec et retour arrière
Section intitulée « Échec et retour arrière »Une vérification ou un téléchargement qui échoue laisse l’application installée inchangée. Un échec de signature bloque l’installation. L’application ne redémarre qu’après l’installation réussie du téléchargement vérifié.
Oleafly ne revient pas automatiquement en arrière après une mise à jour terminée. Pour revenir à une version antérieure, fermez l’application, sauvegardez les projets importants, téléchargez l’installateur officiel antérieur, vérifiez-le, puis installez-le par-dessus la version actuelle.
Voir Publication d’Oleafly pour le processus de brouillon et de publication.