Constructions et versions

Modèle de distribution

La version de bureau contient une interface Vite, un sidecar compilé par Bun et des migrations SQLite générées dans une application Tauri. Le référentiel définit les versions macOS Apple Silicon et Intel, Windows x64 et ARM64, ainsi que Linux x64 et ARM64. L'automatisation des versions est configurée dans .github/workflows/release.yml; les contrôles de construction de plate-forme s'exécutent également indépendamment via build-platforms.yml.

Une définition de workflow décrit le processus de publication. La disponibilité et la validité d'un programme d'installation doivent être établies à partir de ses ressources d'exécution et de version particulières. Le code source à lui seul ne prouve pas les informations d'identification de signature, les résultats de la notarisation ou la réussite de l'installation sur une machine cible.

Construire un pipeline

scripts/build.ts exécute six étapes ordonnées et abandonne lorsqu'une étape échoue :

1. Installer: installation de fichier de verrouillage gelé, y compris les dépendances facultatives pour tous les systèmes d'exploitation et architectures de processeur.
2. Vérifier: vérification du type de l'espace de travail. Les tests unitaires sont une commande CI distincte.
3. Compiler: construire le sidecar avec scripts/compile-sidecar.ts pour le triple cible Rust.
4. Ressources: scène packages/db/drizzle sous forme de migrations groupées.
5. Paquet: créez le frontend, puis invoquez Tauri avec les paramètres de cible, de bundle, de signature et de mise à jour.
6. Artefacts : indexez les ressources du programme d'installation, écrivez des sommes de contrôle SHA-256 et générez des notes de version à partir de l'historique Git.

bun scripts/build.ts --help
bun scripts/build.ts --dry-run
bun run build:sidecar
bun scripts/build.ts --only=resources
bun scripts/build.ts --no-updater

--only et --skip accepter les noms de scène ; --target, --bundles, et --out-dir sélectionner les sorties. La cible par défaut est l'hôte signalé par rustc -vV. Les binaires sidecar sont écrits dans apps/desktop/src-tauri/binaries/sidecar-<triple>, avec .exe sous Windows. Les binaires et arbres de migration identiques restent inchangés pour éviter des redémarrages de développement inutiles.

Utiliser compile-sidecar.ts via le pipeline : il applique les adaptations de regroupement des hôtes intégrés. Une commande de compilation générique directe ne représente pas la même procédure de construction. Le répertoire d'artefacts par défaut est apps/desktop/src-tauri/target/release-artifacts.

Le resources copies étape par étape packages/db/drizzle/ dans apps/desktop/src-tauri/resources/migrations/ et peut être répété en toute sécurité. Le artifacts étape écrit SHA256SUMS et RELEASE_NOTES.md, construit à partir des commits depuis la dernière balise. Les alias d'étape sont acceptés par --only et --skip: deps, checks/test, sidecar, migrations, et notes/checksums/release. Le script ne lit jamais .env* fichiers ou imprime des valeurs secrètes.

CI et publication

Le workflow de publication s'exécute pendant v* balises ou une balise de version existante sélectionnée manuellement sur le référentiel non-fork. release-ref.ts vérifie la version de la balise et de l'application et résout la validation. Chaque build crée une version de plateforme, telle qu'une balise de version suffixée par macos-arm64 ou linux-x64. Ce n'est qu'après la publication de toutes les versions de la plateforme que l'index des versions publie le fichier fusionné. latest.json.

stage-release.ts vérifie les artefacts sélectionnés, les relations somme de contrôle/signature et les liens du manifeste avant la publication. Les versions déjà publiées ne sont pas écrasées. La version d'index peut devenir la dernière pour les versions stables ; les avant-premières restent marquées comme avant-premières.

Les versions du programme de mise à jour nécessitent la configuration de la clé privée de signature Tauri et du mot de passe correspondant à la clé publique dans tauri.conf.json. la signature/notarisation de la version macOS utilise le certificat Apple et les paramètres du compte ; Windows importe un certificat de signature et transmet son empreinte au bundler. Les entrées de signature de version requises manquantes font échouer la version de version. Configurez-les via le magasin de secrets CI.

Une tâche de version distincte publie le package du plug-in nikcli lorsqu'un jeton npm est disponible. Il ignore une version déjà publiée et peut utiliser le nom du package de secours configuré lorsque la portée principale ne peut pas être publiée. Cette tâche de package n'établit pas la disponibilité du programme d'installation de bureau.

Comportement du programme de mise à jour

Le point de terminaison du programme de mise à jour configuré est la dernière version téléchargée de GitHub du référentiel à l'adresse latest.json. Le programme de mise à jour Rust effectue des vérifications au lancement et toutes les quatre heures, avec des vérifications manuelles mises en file d'attente via son service. Chaque requête utilise un délai d'expiration de 30 secondes. Le manifeste identifie les actifs et les signatures spécifiques à la plateforme ; la clé publique fait partie de la configuration de l'application.

update://status comporte les états de vérification, à jour, disponible, en téléchargement, prêt et en échec. Notes de version contenant [critical] marquer la mise à jour disponible comme non rejetable. Un état prêt à redémarrer est également incontournable. Cela affecte l'invite ; l'installation respecte toujours la garde des travaux non sauvegardés.

install_update enregistre et revérifie la version annoncée, puis télécharge un package avec signature vérifiée. L'éditeur enregistre avant le téléchargement et à nouveau avant apply_update, protégeant les modifications effectuées lors du téléchargement. Le travail non enregistré bloque les deux opérations ; les sauvegardes échouées conservent les octets vérifiés pour une nouvelle tentative. Le statut natif est récupéré après l'abonnement et les vérifications ne peuvent pas remplacer une progression active ou un redémarrage en attente. Windows vide le sidecar avant que son installateur ne prenne le contrôle ; d'autres plateformes proposent un redémarrage après l'installation.

Compatibilité des bases de données

Applications packagées ouvertes cadcamfun.db dans leur répertoire de données d'application. Les migrations en attente sont appliquées par la couche de base de données au démarrage à l'aide des migrations incluses dans le bundle. Les mises à niveau de schéma et les mises à jour binaires sont donc liées même s'il s'agit d'artefacts distincts.

Les notes de version générées comparent les arborescences de migration suivies avec la balise de version précédente. Une arborescence modifiée est signalée comme dangereuse pour une rétrogradation ; une arborescence inchangée est signalée comme compatible avec la migration ; l’historique indisponible est signalé comme inconnu. Cette comparaison automatisée ne valide pas tous les problèmes possibles de compatibilité au niveau des applications.

Avant de remplacer un binaire par une ancienne version, conservez les données actuelles et inspectez les notes de compatibilité de la version. Le code de migration vers l’avant n’implique pas les migrations inverses. Suivez les procédures de sauvegarde et de récupération de la base de données pour le répertoire de données réel.

Vérification de la version

bun test scripts
bun scripts/build.ts --only=artifacts --dry-run

Les tests d'assistance valident le mappage des cibles, les exigences de signature, la dénomination des artefacts, la gestion des manifestes et les règles de transfert. Un essai à sec imprime les opérations planifiées sans compilation ni signature. Ni ne remplace un package natif réel, un test de téléchargement/d’installation du programme de mise à jour, ni l’acceptation d’un appareil physique pour le compagnon.

Pour une version opérationnelle, conservez la balise/validation exacte, le résultat du flux de travail, le programme d'installation et la mise à jour spécifiques à la cible, les fichiers de somme de contrôle/signature et le manifeste publié. Vérifiez que l'application installée démarre son sidecar et ses migrations groupés et que le programme de mise à jour sélectionne l'actif de plate-forme prévu.

Référence cible et actif

Le générateur nécessite exactement un actif par format ci-dessus, son adjacent .sig fichier et les notes de version. Les noms d'actifs utilisent un <triple>-- préfixe; les noms en double et les signatures orphelines sont refusés. Le programme de mise à jour Tauri 2.13.1 sélectionne automatiquement le type de package installé ; Linux utilise des packages Debian/RPM signés sans AppImage.

Les manifestes fusionnés doivent convenir sur la version, la date de publication et les notes. La publication nécessite les dix clés ci-dessus. Les clés de base Windows conservent la compatibilité NSIS pour les clients plus anciens ; Les clés MSI préservent les installations MSI. Les URL doivent utiliser HTTPS sans informations d'identification, requête ou fragment. La mise en scène vérifie chaque préfixe cible, suffixe de package, signature et URL de version.

Options de construction locales et entrées de signature

bun --no-env-file scripts/build.ts   --only=compile,resources   --target=aarch64-apple-darwin   --dry-run

bun --no-env-file scripts/build.ts   --skip=install,check   --target=x86_64-unknown-linux-gnu   --bundles=deb,rpm   --no-updater   --dry-run

Retirer --dry-run uniquement lorsque la chaîne d'outils cible sélectionnée et les prérequis natifs sont installés. La compilation croisée de l'exécutable Bun ne fournit pas en soi un éditeur de liens et un bundler Tauri multiplateforme. --only et --skip s'excluent mutuellement ; --skip-install est un alias pratique. --no-updater omet la création de l'archive/signature du programme de mise à jour et sa porte de signature.

La build charge les informations d'identification du programme de mise à jour local uniquement pour l'étape de regroupement et transmet les valeurs de signature via l'environnement à ce processus enfant. N'imprimez pas de fichiers de signature locaux et ne placez pas de véritables éléments de clé dans un exemple de documentation. Une clé privée qui ne correspond pas à la clé publique d'une application installée ne peut pas produire une mise à jour acceptée pour cette application.

Diagnostic d'échec de la version

Un rapport de version utile enregistre quelle étape a échoué et quelle cible elle était en cours de construction. Incluez les noms d'artefacts non secrets, les erreurs de validation et les identifiants de flux de travail. Conserver la version précédente installée et une sauvegarde des données vérifiées disponibles lors d'un exercice de mise à jour ; la compatibilité de la migration est vérifiée séparément de la validité de la signature.

Ancres de mise en œuvre : scripts/release-helpers.ts, signing-config.ts, updater-manifest.ts, stage-release.ts, et apps/desktop/src-tauri/src/updater.rs.

Les six étapes de construction

Les étapes s'exécutent toujours dans cet ordre et une étape qui échoue arrête l'exécution. Le script ne lit jamais .env fichiers et n’imprime jamais les valeurs secrètes.

bun scripts/build.ts --dry-run                  # whole plan, no side effects
bun scripts/build.ts --only=resources           # restage migrations (idempotent)
bun scripts/build.ts --only=compile,resources   # rebuild the sidecar and migrations
bun scripts/build.ts --only=notes --dry-run     # preview release notes
bun scripts/build.ts --target=aarch64-apple-darwin

La signature du programme de mise à jour local utilise un tauri-signing.json lorsqu'aucune clé de signature n'est définie dans l'environnement. Les certificats de plateforme sont toujours requis lorsque CADCAM_RELEASE=1.

Matrice de version

1. Une tâche approuvée valide la balise de version par rapport à la version de l'application.
2. Chaque tâche matricielle s'exécute bun --no-env-file scripts/build.ts --target=… --bundles=… --out-dir=release, signe et crée un manifeste pour ses formats de package. Windows importe puis supprime son certificat de signature facultatif.
3. Une tâche de fusion valide les six manifestes d'architecture et leurs dix entrées de package en un seul latest.json.
4. Une tâche d'achèvement vérifie tous les artefacts, signatures, sommes de contrôle et notes du programme d'installation avant de créer ou de reprendre la version unique et de la publier.

CI à chaque push exécute deux tâches : installer, vérifier le type et tester (et organiser le binaire sidecar et les migrations), et une tâche Rust avec clippy et le src-tauri essais.

En 3D