Builds und Veröffentlichungen

Vertriebsmodell

Der Desktop-Build bündelt ein Vite-Frontend, einen Bun-kompilierten Sidecar und generierte SQLite-Migrationen in einer Tauri-Anwendung. Das Repository definiert macOS Apple Silicon- und Intel-, Windows x64- und ARM64- sowie Linux x64- und ARM64-Builds. Die Release-Automatisierung ist in konfiguriert .github/workflows/release.yml; plattform-Build-Prüfungen laufen auch unabhängig voneinander ab build-platforms.yml.

Eine Workflow-Definition beschreibt den Veröffentlichungsprozess. Die Verfügbarkeit und Gültigkeit eines Installationsprogramms muss anhand seiner jeweiligen Ausführungs- und Release-Assets festgestellt werden. Der Quellcode allein ist kein Beweis für die Signaturberechtigung, die Beglaubigungsergebnisse oder die erfolgreiche Installation auf einem Zielcomputer.

Pipeline erstellen

scripts/build.ts führt sechs geordnete Phasen durch und bricht ab, wenn eine Phase fehlschlägt:

1. Installieren: frozen-Lockfile-Installation, einschließlich optionaler Abhängigkeiten für alle Betriebssysteme und CPU-Architekturen.
2. Überprüfen: typprüfung des Arbeitsbereichs. Unit-Tests sind ein separater CI-Befehl.
3. Kompilieren: baue den Sidecar mit scripts/compile-sidecar.ts für das Rust-Ziel-Triple.
4. Ressourcen: bühne packages/db/drizzle als gebündelte Migrationen.
5. Bündeln: erstellen Sie das Frontend und rufen Sie dann Tauri mit Ziel-, Bundle-, Signierungs- und Updater-Einstellungen auf.
6. Artefakte: indexieren Sie Installer-Assets, schreiben Sie SHA-256-Prüfsummen und generieren Sie Versionshinweise aus dem Git-Verlauf.

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 und --skip künstlernamen akzeptieren; --target, --bundles, und --out-dir ausgänge auswählen. Das Standardziel ist der von gemeldete Host rustc -vV. In Sidecar-Binärdateien wird geschrieben apps/desktop/src-tauri/binaries/sidecar-<triple>, mit .exe unter Windows. Identische Binärdateien und Migrationsbäume bleiben unverändert, um unnötige Entwicklungsneustarts zu vermeiden.

Verwenden compile-sidecar.ts durch die Pipeline: Es wendet die eingebetteten Host-Bündelungsanpassungen an. Ein direkter generischer Kompilierungsbefehl stellt nicht dieselbe Erstellungsprozedur dar. Das Standardartefaktverzeichnis ist apps/desktop/src-tauri/target/release-artifacts.

Der resources schrittkopien packages/db/drizzle/ hinein apps/desktop/src-tauri/resources/migrations/ und kann problemlos wiederholt werden. Der artifacts schritt schreibt SHA256SUMS und RELEASE_NOTES.md, erstellt aus den Commits seit dem letzten Tag. Schrittaliase werden akzeptiert von --only und --skip: deps, checks/test, sidecar, migrations, und notes/checksums/release. Das Skript liest nie .env* speichert oder druckt geheime Werte.

CI und Veröffentlichung

Der Freigabeworkflow läuft für v* tags oder ein manuell ausgewähltes vorhandenes Versions-Tag im Nicht-Fork-Repository. release-ref.ts prüft das Tag und die Anwendungsversion und löst den Commit auf. Jeder Build erstellt eine Plattformversion, beispielsweise ein Versions-Tag mit dem Suffix macos-arm64 oder linux-x64. Erst nachdem alle Plattformversionen veröffentlicht wurden, veröffentlicht der Versionsindex die zusammengeführten Versionen latest.json.

stage-release.ts prüft die ausgewählten Artefakte, Prüfsummen-/Signaturbeziehungen und Manifest-Links vor der Veröffentlichung. Bereits veröffentlichte Veröffentlichungen werden nicht überschrieben. Die Indexversion kann für stabile Versionen die neueste sein; Vorabversionen bleiben als Vorabversionen gekennzeichnet.

Updater-Builds erfordern die Konfiguration des privaten Signaturschlüssels und des Kennworts von Tauri, die dem öffentlichen Schlüssel entspricht tauri.conf.json. für die Signierung/Beglaubigung von macOS-Versionen werden Apple-Zertifikate und Kontoeinstellungen verwendet. Windows importiert ein Signaturzertifikat und übergibt seinen Fingerabdruck an den Bundler. Fehlende erforderliche Release-Signatureingaben schlagen beim Release-Build fehl. Konfigurieren Sie diese über den CI Secret Store.

Ein separater Release-Job veröffentlicht das Nikcli-Plugin-Paket, wenn ein NPM-Token verfügbar ist. Es überspringt eine bereits veröffentlichte Version und kann den konfigurierten Fallback-Paketnamen verwenden, wenn der primäre Bereich nicht veröffentlicht werden kann. Dieser Paketauftrag stellt nicht die Verfügbarkeit des Desktop-Installationsprogramms her.

Updater-Verhalten

Der konfigurierte Updater-Endpunkt ist der neueste GitHub-Release-Download des Repositorys unter latest.json. Der Rust-Updater prüft beim Start und alle vier Stunden, wobei manuelle Prüfungen über seinen Dienst in die Warteschlange gestellt werden. Jede Anfrage verwendet ein 30-Sekunden-Timeout. Das Manifest identifiziert plattformspezifische Assets und Signaturen; Der öffentliche Schlüssel ist Teil der Anwendungskonfiguration.

update://status enthält die Status „Prüfung“, „Aktuell“, „Verfügbar“, „Herunterladen“, „Bereit“ und „Fehler“. Versionshinweise enthalten [critical] markieren Sie das verfügbare Update als nicht verwerfbar. Auch der Status „Bereit zum Neustart“ kann nicht abgewiesen werden. Dies wirkt sich auf die Eingabeaufforderung aus. Die Installation berücksichtigt weiterhin den Schutz für nicht gespeicherte Arbeiten.

install_update zeichnet die angekündigte Version auf, überprüft sie erneut und lädt dann ein signaturverifiziertes Paket herunter. Der Editor speichert vor dem Download und noch einmal davor apply_update, um die während des Downloads vorgenommenen Änderungen zu schützen. Nicht gespeicherte Arbeit blockiert beide Vorgänge; Bei fehlgeschlagenen Speicherungen werden überprüfte Bytes für einen erneuten Versuch beibehalten. Der native Status wird nach dem Abonnieren wiederhergestellt und Überprüfungen können den aktiven Fortschritt oder einen ausstehenden Neustart nicht ersetzen. Windows entleert den Sidecar, bevor sein Installationsprogramm die Kontrolle übernimmt; Andere Plattformen bieten einen Neustart nach der Installation an.

Datenbankkompatibilität

Gepackte Anwendungen werden geöffnet cadcamfun.db in ihrem Anwendungsdatenverzeichnis. Ausstehende Migrationen werden von der Datenbankschicht beim Start mithilfe der im Bundle enthaltenen Migrationen angewendet. Schema-Upgrades und Binäraktualisierungen hängen daher zusammen, obwohl es sich um separate Artefakte handelt.

Generierte Versionshinweise vergleichen verfolgte Migrationsbäume mit dem vorherigen Release-Tag. Ein geänderter Baum wird als unsicher für ein Downgrade gemeldet; ein unveränderter Baum wird als migrationskompatibel gemeldet; Der nicht verfügbare Verlauf wird als unbekannt gemeldet. Dieser automatisierte Vergleich validiert nicht jedes mögliche Kompatibilitätsproblem auf Anwendungsebene.

Bevor Sie eine Binärdatei durch eine ältere Version ersetzen, bewahren Sie die aktuellen Daten auf und prüfen Sie die Kompatibilitätshinweise der Version. Der Vorwärtsmigrationscode impliziert keine Rückwärtsmigrationen. Befolgen Sie die Verfahren zur Datenbanksicherung und -wiederherstellung für das tatsächliche Datenverzeichnis.

Freigabeverifizierung

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

Hilfstests validieren die Zielzuordnung, Signaturanforderungen, Artefaktbenennung, Manifestverarbeitung und Staging-Regeln. Ein Probelauf druckt geplante Vorgänge ohne Kompilierung oder Signierung. Kein Ersatz für ein tatsächliches natives Bundle, einen Updater-Download-/Installationstest oder die Akzeptanz des Begleiters auf einem physischen Gerät.

Behalten Sie für eine betriebsbereite Version das genaue Tag/Commit, das Workflow-Ergebnis, das zielspezifische Installationsprogramm und Update-Asset, die Prüfsumme/Signaturdateien und das veröffentlichte Manifest bei. Überprüfen Sie, ob die installierte App ihren gebündelten Sidecar und ihre Migrationen startet und dass der Updater das gewünschte Plattform-Asset auswählt.

Ziel- und Vermögensreferenz

Der Generator benötigt genau ein Asset pro Format oben, das angrenzende .sig datei und Versionshinweise. Asset-Namen verwenden a <triple>-- präfix; Doppelte Namen und verwaiste Unterschriften werden abgelehnt. Der Tauri-Updater 2.13.1 wählt den installierten Pakettyp automatisch aus; Linux verwendet signierte Debian/RPM-Pakete ohne AppImage.

Zusammengeführte Manifeste müssen hinsichtlich Version, Veröffentlichungsdatum und Anmerkungen übereinstimmen. Für die Veröffentlichung sind alle zehn oben genannten Schlüssel erforderlich. Windows-Basisschlüssel behalten die NSIS-Kompatibilität für ältere Clients bei; MSI-Schlüssel bewahren MSI-Installationen. URLs müssen HTTPS ohne Anmeldeinformationen, eine Abfrage oder ein Fragment verwenden. Beim Staging werden alle Zielpräfixe, Paketsuffixe, Signaturen und Release-URLs überprüft.

Lokale Build-Optionen und Signierungseingaben

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

Entfernen --dry-run nur wenn die ausgewählte Ziel-Toolchain und die nativen Voraussetzungen installiert sind. Durch die übergreifende Kompilierung der ausführbaren Bun-Datei wird kein plattformübergreifender Tauri-Linker und -Bundler bereitgestellt. --only und --skip schließen sich gegenseitig aus; --skip-install ist ein Bequemlichkeitsalias. --no-updater lässt die Erstellung von Updater-Archiven/Signaturen und dessen Signatur-Gate aus.

Der Build lädt lokale Updater-Anmeldeinformationen nur für den Bündelungsschritt und übergibt Signaturwerte über die Umgebung an diesen untergeordneten Prozess. Drucken Sie keine lokalen Signaturdateien aus und platzieren Sie kein echtes Schlüsselmaterial in einem Dokumentationsbeispiel. Ein privater Schlüssel, der nicht mit dem öffentlichen Schlüssel einer installierten App übereinstimmt, kann kein akzeptiertes Update für diese App erzeugen.

Diagnose von Freigabefehlern

Ein nützlicher Release-Bericht zeichnet auf, welche Phase fehlgeschlagen ist und welches Ziel erstellt wurde. Schließen Sie nicht geheime Artefaktnamen, Validierungsfehler und Workflow-IDs ein. Halten Sie während einer Updater-Übung die zuvor installierte Version und eine überprüfte Datensicherung bereit. Die Migrationskompatibilität wird getrennt von der Signaturgültigkeit geprüft.

Umsetzungsanker: scripts/release-helpers.ts, signing-config.ts, updater-manifest.ts, stage-release.ts, und apps/desktop/src-tauri/src/updater.rs.

Die sechs Bauschritte

Schritte werden immer in dieser Reihenfolge ausgeführt und ein fehlgeschlagener Schritt stoppt die Ausführung. Das Skript liest nie .env dateien und gibt niemals geheime Werte aus.

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

Die lokale Updater-Signierung verwendet eine ignorierte Option tauri-signing.json wenn in der Umgebung kein Signaturschlüssel festgelegt ist. Plattformzertifikate sind weiterhin erforderlich, wenn CADCAM_RELEASE=1.

Release-Matrix

1. Ein vertrauenswürdiger Job validiert das Release-Tag anhand der Anwendungsversion.
2. Jeder Matrixjob wird ausgeführt bun --no-env-file scripts/build.ts --target=… --bundles=… --out-dir=release, signiert und erstellt ein Manifest für seine Paketformate. Windows importiert und entfernt anschließend sein optionales Signaturzertifikat.
3. Ein Zusammenführungsauftrag validiert alle sechs Architekturmanifeste und ihre zehn Paketeinträge in einem latest.json.
4. Ein Abschlussjob überprüft alle Artefakte, Signaturen, Prüfsummen und Notizen des Installationsprogramms, bevor die Einzelversionsversion erstellt oder fortgesetzt und veröffentlicht wird.

CI führt bei jedem Push zwei Jobs aus: Installation, Typprüfung und Test (und stellt die Sidecar-Binärdatei und Migrationen bereit) und einen Rust-Job mit Clippy und dem src-tauri tests.

In 3D