Costruisce e rilascia

Modello distributivo

La build desktop racchiude un frontend Vite, un sidecar compilato con Bun e ha generato migrazioni SQLite in un'applicazione Tauri. Il repository definisce le build macOS Apple Silicon e Intel, Windows x64 e ARM64 e Linux x64 e ARM64. L'automazione del rilascio è configurata in .github/workflows/release.yml; anche i controlli sulla creazione della piattaforma vengono eseguiti in modo indipendente build-platforms.yml.

Una definizione del flusso di lavoro descrive il processo di pubblicazione. La disponibilità e la validità di un programma di installazione devono essere stabilite dalle sue particolari risorse di esecuzione e rilascio. Il solo codice sorgente non dimostra le credenziali di firma, i risultati dell'autenticazione o l'installazione riuscita su una macchina di destinazione.

Costruisci una pipeline

scripts/build.ts esegue sei fasi ordinate e si interrompe quando una fase fallisce:

1. Installare: installazione di frozen-lockfile, incluse dipendenze opzionali per tutti i sistemi operativi e le architetture della CPU.
2. Controllo: controllo del tipo di spazio di lavoro. I test unitari sono un comando CI separato.
3. Compilare: costruisci il sidecar con scripts/compile-sidecar.ts per il target Rust triplo.
4. Risorse: palcoscenico packages/db/drizzle come migrazioni raggruppate.
5. Fascio: crea il frontend, quindi richiama Tauri con le impostazioni di destinazione, bundle, firma e aggiornamento.
6. Artefatti: indicizzare le risorse del programma di installazione, scrivere checksum SHA-256 e generare note di rilascio dalla cronologia di 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 e --skip accettare nomi d'arte; --target, --bundles, e --out-dir selezionare le uscite. La destinazione predefinita è l'host segnalato da rustc -vV. Vengono scritti i binari del sidecar apps/desktop/src-tauri/binaries/sidecar-<triple>, con .exe su Windows. I file binari e gli alberi di migrazione identici vengono mantenuti invariati per evitare riavvii di sviluppo non necessari.

Utilizzo compile-sidecar.ts attraverso la pipeline: applica gli adattamenti del raggruppamento di host incorporati. Un comando di compilazione generico diretto non rappresenta la stessa procedura di compilazione. La directory degli artefatti predefinita è apps/desktop/src-tauri/target/release-artifacts.

Il resources copie del passo packages/db/drizzle/ in apps/desktop/src-tauri/resources/migrations/ ed è sicuro ripeterlo. IL artifacts passo scrive SHA256SUMS e RELEASE_NOTES.md, creato dai commit dall'ultimo tag. Gli alias dei passaggi sono accettati da --only e --skip: deps, checks/test, sidecar, migrations, e notes/checksums/release. La sceneggiatura non viene mai letta .env* file o stampa valori segreti.

CI e pubblicazione

Il flusso di lavoro di rilascio viene eseguito per v* tag o un tag di versione esistente selezionato manualmente sul repository non-fork. release-ref.ts controlla il tag e la versione dell'applicazione e risolve il commit. Ogni build crea una versione della piattaforma, ad esempio un tag di versione con suffisso macos-arm64 o linux-x64. Solo dopo la pubblicazione di tutte le versioni della piattaforma, l'indice delle versioni pubblica quelle unite latest.json.

stage-release.ts controlla gli artefatti selezionati, le relazioni checksum/firma e i collegamenti manifest prima della pubblicazione. Le versioni già pubblicate non vengono sovrascritte. La versione dell'indice può diventare l'ultima per le versioni stabili; le prerelease rimangono contrassegnate come prerelease.

Le build del programma di aggiornamento richiedono la chiave privata di firma Tauri e la configurazione della password corrispondente alla chiave pubblica di accesso tauri.conf.json. la firma/autenticazione della versione di macOS utilizza il certificato Apple e le impostazioni dell'account; Windows importa un certificato di firma e ne trasmette l'identificazione personale al bundler. Gli input di firma della versione richiesti mancanti non riescono a completare la creazione della versione. Configurarli tramite l'archivio segreto CI.

Un processo di rilascio separato pubblica il pacchetto del plugin nikcli quando è disponibile un token npm. Salta una versione già pubblicata e può utilizzare il nome del pacchetto fallback configurato quando non è possibile pubblicare l'ambito primario. Questo processo di pacchetto non stabilisce la disponibilità del programma di installazione desktop.

Comportamento dell'aggiornamento

L'endpoint del programma di aggiornamento configurato è l'ultimo download della versione GitHub del repository su latest.json. L'aggiornamento di Rust effettua controlli all'avvio e ogni quattro ore, con controlli manuali messi in coda tramite il suo servizio. Ogni richiesta utilizza un timeout di 30 secondi. Il manifest identifica risorse e firme specifiche della piattaforma; la chiave pubblica fa parte della configurazione dell'applicazione.

update://status trasporta gli stati di verifica, aggiornamento, disponibile, download, pronto e non riuscito. Note di rilascio contenenti [critical] contrassegnare l'aggiornamento disponibile come non eliminabile. Anche uno stato pronto per il riavvio non è eliminabile. Ciò influisce sul prompt; l'installazione rispetta comunque la protezione del lavoro non salvato.

install_update registra e ricontrolla la versione annunciata, quindi scarica un pacchetto con firma verificata. L'editor salva prima del download e ancora prima apply_update, proteggendo le modifiche apportate durante il download. Il lavoro non salvato blocca entrambe le operazioni; i salvataggi non riusciti conservano i byte verificati per riprovare. Lo stato nativo viene ripristinato dopo la sottoscrizione e i controlli non possono sostituire l'avanzamento attivo o un riavvio in sospeso. Windows scarica il sidecar prima che il suo installatore prenda il controllo; altre piattaforme offrono un riavvio dopo l'installazione.

Compatibilità con database

Si aprono le applicazioni in pacchetto cadcamfun.db nella directory dei dati dell'applicazione. Le migrazioni in sospeso vengono applicate dal livello del database all'avvio utilizzando le migrazioni incluse nel pacchetto. Gli aggiornamenti dello schema e gli aggiornamenti binari sono quindi correlati anche se sono elementi separati.

Le note di rilascio generate confrontano gli alberi di migrazione tracciati con il tag di rilascio precedente. Un albero modificato viene segnalato come non sicuro per il downgrade; un albero invariato viene segnalato come compatibile con la migrazione; la cronologia non disponibile viene segnalata come sconosciuta. Questo confronto automatizzato non convalida ogni possibile problema di compatibilità a livello di applicazione.

Prima di sostituire un binario con una versione precedente, conserva i dati correnti e controlla le note di compatibilità della versione. Il codice di migrazione diretta non implica migrazioni inverse. Seguire le procedure di backup e ripristino del database per la directory dei dati effettiva.

Verifica del rilascio

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

I test di supporto convalidano la mappatura delle destinazioni, i requisiti di firma, la denominazione degli artefatti, la gestione dei manifest e le regole di gestione temporanea. Un'esecuzione di prova stampa le operazioni pianificate senza compilare o firmare. Né sostituisce un pacchetto nativo effettivo, né un test di download/installazione dell'aggiornamento, né l'accettazione del dispositivo fisico per il compagno.

Per una versione operativa, conservare il tag/commit esatto, il risultato del flusso di lavoro, il programma di installazione e la risorsa di aggiornamento specifici della destinazione, i file di checksum/firma e il manifest pubblicato. Verifica che l'app installata avvii il sidecar e le migrazioni in bundle e che il programma di aggiornamento selezioni la risorsa della piattaforma prevista.

Obiettivo e riferimento dell'asset

Il generatore richiede esattamente una risorsa per formato sopra, adiacente .sig file e note di rilascio. I nomi delle risorse utilizzano a <triple>-- prefisso; i nomi duplicati e le firme orfane vengono rifiutati. Il programma di aggiornamento Tauri 2.13.1 seleziona automaticamente il tipo di pacchetto installato; Linux utilizza pacchetti Debian/RPM firmati senza AppImage.

I manifest uniti devono concordare su versione, data di pubblicazione e note. La pubblicazione richiede tutte e dieci le chiavi sopra. Le chiavi di base di Windows mantengono la compatibilità NSIS per i client meno recenti; Le chiavi MSI preservano le installazioni MSI. Gli URL devono utilizzare HTTPS senza credenziali, query o frammenti. La gestione temporanea controlla ogni prefisso di destinazione, suffisso del pacchetto, firma e URL di rilascio.

Opzioni di compilazione locale e input di firma

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

Rimuovere --dry-run solo quando sono installati la toolchain di destinazione selezionata e i prerequisiti nativi. La compilazione incrociata dell'eseguibile Bun non fornisce di per sé un linker e un bundler Tauri multipiattaforma. --only e --skip si escludono a vicenda; --skip-install è uno pseudonimo di convenienza. --no-updater omette la creazione dell'archivio/firma dell'aggiornamento e il relativo cancello di firma.

La build carica le credenziali del programma di aggiornamento locale solo per la fase di raggruppamento e passa i valori di firma attraverso l'ambiente a quel processo figlio. Non stampare file di firma locali né inserire materiale chiave reale in un esempio di documentazione. Una chiave privata che non corrisponde alla chiave pubblica di un'app installata non può produrre un aggiornamento accettato per quell'app.

Diagnosi del fallimento del rilascio

Un utile report di rilascio registra quale fase non è riuscita e quale destinazione stava creando. Includi nomi di artefatti non segreti, errori di convalida e identificatori del flusso di lavoro. Mantenere disponibili la versione installata precedente e un backup dei dati verificato durante un esercizio di aggiornamento; la compatibilità della migrazione viene verificata separatamente dalla validità della firma.

Ancore di implementazione: scripts/release-helpers.ts, signing-config.ts, updater-manifest.ts, stage-release.ts, e apps/desktop/src-tauri/src/updater.rs.

I sei passaggi di costruzione

I passaggi vengono sempre eseguiti in questo ordine e un passaggio non riuscito interrompe l'esecuzione. La sceneggiatura non viene mai letta .env files e non stampa mai valori segreti.

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 firma del programma di aggiornamento locale utilizza un file ignorato tauri-signing.json quando nell'ambiente non è impostata alcuna chiave di firma. I certificati della piattaforma sono ancora necessari quando CADCAM_RELEASE=1.

Matrice di rilascio

1. Un lavoro attendibile convalida il tag di rilascio rispetto alla versione dell'applicazione.
2. Ogni lavoro della matrice viene eseguito bun --no-env-file scripts/build.ts --target=… --bundles=… --out-dir=release, firma e crea un manifest per i suoi formati di pacchetto. Windows importa e successivamente rimuove il relativo certificato di firma opzionale.
3. Un processo di unione convalida tutti e sei i manifesti dell'architettura e le relative dieci voci di pacchetto in uno solo latest.json.
4. Un processo di completamento verifica tutti gli artefatti, le firme, i checksum e le note del programma di installazione prima di creare o riprendere il rilascio della versione singola e pubblicarla.

CI su ogni push esegue due lavori: installazione, controllo del tipo e test (e mette in scena il binario sidecar e le migrazioni), e un lavoro Rust con clippy e il src-tauri test.

Nel 3D