For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /fr/docs/desktop/updates.md (or send Accept: text/markdown).

Mises à jour automatiques et canaux de publication

Flux de mises à jour signés, canal stable/bêta et workflow de publication livré.

Poser une question sur ce guide

Générer la paire de clés de l'updater une fois

L'updater vérifie les signatures minisign des artefacts téléchargés. Générez une paire de clés avec le signataire Tauri et conservez la clé privée dans TAURI_SIGNING_PRIVATE_KEY avec son mot de passe dans TAURI_SIGNING_PRIVATE_KEY_PASSWORD, les deux dans votre coffre de secrets — jamais dans le dépôt. Les builds qui créent des artefacts d'updater émettent un fichier annexe .sig à côté de chaque installateur ; la clé publique va aux clients, la clé privée reste dans la CI.

corepack pnpm --filter @supastack/desktop exec tauri signer generate -w ~/.tauri/product.key

Configurer l'updater au moment de la build

tauri.conf.json livre un bloc updater sentinelle avec des endpoints et un pubkey vides — conservez-le, car le plugin updater ne peut pas s'initialiser sans ces clés présentes. Les vraies valeurs sont fusionnées en profondeur au moment de la build via une surcouche JSON --config ou la variable d'environnement TAURI_CONFIG ; check:release-config affiche la surcouche exacte à coller quand SUPASTACK_UPDATER_ENDPOINT et SUPASTACK_UPDATER_PUBKEY sont définies.

Définissez les deux ou aucune : une surcouche limitée aux endpoints laisse le pubkey vide, donc les vérifications semblent fonctionner alors que chaque installation échoue à la vérification de signature. L'URL d'endpoint porte les paramètres {{target}}, {{arch}} et {{current_version}} — l'emplacement de version est requis — plus un segment de chemin {{channel}} optionnel qui active les canaux de publication.

# check:release-config prints this overlay for tauri build --config:
# {"plugins":{"updater":{"endpoints":["https://releases.example.com/{{channel}}/{{target}}/{{arch}}/{{current_version}}"],"pubkey":"<base64 public key>"}}}
# SUPASTACK_UPDATER_ENDPOINT=
# SUPASTACK_UPDATER_PUBKEY=

Publier le flux latest.json

Chaque endpoint répond un manifeste latest.json — version, notes, pub_date et une carte platforms couvrant darwin-aarch64, darwin-x86_64, windows-x86_64, windows-aarch64, linux-x86_64 et linux-aarch64 — où chaque entrée associe l'URL de l'installateur à sa signature.

Construisez-le avec le script release:manifest : il balaie un répertoire de bundle à la recherche d'artefacts .app.tar.gz, -setup.exe (préféré à .msi) et .AppImage — chacun doit avoir son voisin .sig — puis écrit ou fusionne le manifeste. Les drapeaux couvrent --version, --base-url, --bundle-dir avec --platform, --merge pour accumuler les plateformes entre exécutions, --notes, --pub-date et --out.

corepack pnpm --filter @supastack/desktop release:manifest -- \
  --version 1.2.0 \
  --base-url https://releases.example.com/stable \
  --bundle-dir src-tauri/target/release/bundle \
  --platform windows-x86_64 \
  --merge latest.json

Canaux stable et bêta

Quand un endpoint contient le paramètre {{channel}}, le menu de l'application active une case à cocher Beta Updates qui fait basculer le flux entre stable et beta. Le choix persiste dans un fichier update-channel à côté de la configuration de l'application ; SUPASTACK_UPDATE_CHANNEL l'écrase pour l'exécution — toute valeur non reconnue est ignorée avec un avertissement — et stable est la valeur par défaut. Sans le paramètre, la bascule reste désactivée et seul le flux stable est consulté.

Quand les mises à jour sont vérifiées

Une vérification silencieuse en arrière-plan s'exécute au démarrage et n'affiche une boîte de dialogue que si une mise à jour existe ; l'entrée de menu Check for Updates… rapporte chaque issue. Les vérifications se sérialisent — une seconde requête concurrente est abandonnée. Une mise à jour disponible propose Install and Restart, qui télécharge, installe et redémarre l'application ; les builds non configurées répondent que les mises à jour ne sont pas configurées, et les échecs apparaissent en boîtes de dialogue plutôt qu'en nouvelles tentatives.

Le workflow de publication livré

.github/workflows/desktop-release.yml construit la matrice — macOS sur les deux architectures, Windows et Ubuntu — sur les étiquettes desktop-v* ou par déclenchement manuel avec une version et un canal. Il inscrit la version du manifeste depuis l'étiquette (une publication qui l'omet se propose en mise à jour indéfiniment), fusionne les manifestes par plateforme et crée un brouillon de version GitHub portant latest.json plus chaque installateur et signature — marqué prerelease pour les canaux bêta.

Il a besoin de SUPASTACK_APP_URL et SUPASTACK_UPDATER_ENDPOINT comme variables de dépôt, ainsi que de SUPASTACK_UPDATER_PUBKEY, de la clé privée de signature et de son mot de passe comme secrets ; les identifiants de signature Apple sont des ajouts optionnels. Le runbook complet se trouve dans docs/desktop-updates.md du dépôt.

Vérification et dépannage

Installez une build, publiez un manifeste plus récent sur un flux de test, et confirmez que la boîte de dialogue de mise à jour arrive à la vérification suivante et que l'application redémarre sous la nouvelle version. Passez ensuite en bêta et confirmez que la réponse du flux du canal change.