Compilações e lançamentos

Modelo de distribuição

A compilação do desktop empacota um frontend Vite, um sidecar compilado em Bun e gerou migrações SQLite em um aplicativo Tauri. O repositório define compilações macOS Apple Silicon e Intel, Windows x64 e ARM64 e Linux x64 e ARM64. A automação de liberação é configurada em .github/workflows/release.yml; verificações de construção de plataforma também são executadas de forma independente por meio build-platforms.yml.

Uma definição de fluxo de trabalho descreve o processo de publicação. A disponibilidade e a validade de um instalador devem ser estabelecidas a partir de seus ativos específicos de execução e liberação. O código-fonte por si só não prova credenciais de assinatura, resultados de reconhecimento de firma ou instalação bem-sucedida em uma máquina de destino.

Construir pipeline

scripts/build.ts executa seis estágios ordenados e aborta quando um estágio falha:

1. Instalar: instalação de frozen-lockfile, incluindo dependências opcionais para todos os sistemas operacionais e arquiteturas de CPU.
2. Verificar: verificação de tipo do espaço de trabalho. Os testes de unidade são um comando CI separado.
3. Compilar: construir o sidecar com scripts/compile-sidecar.ts para o alvo Rust triplo.
4. Recursos: estágio packages/db/drizzle como migrações agrupadas.
5. Pacote: construa o front-end e, em seguida, invoque o Tauri com configurações de destino, pacote, assinatura e atualizador.
6. Artefatos: indexe ativos do instalador, escreva somas de verificação SHA-256 e gere notas de versão a partir do histórico do 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 aceitar nomes artísticos; --target, --bundles, e --out-dir selecione saídas. O alvo padrão é o host relatado por rustc -vV. Binários sidecar são gravados em apps/desktop/src-tauri/binaries/sidecar-<triple>, com .exe no Windows. Binários idênticos e árvores de migração são mantidos inalterados para evitar reinicializações desnecessárias do desenvolvimento.

Usar compile-sidecar.ts através do pipeline: aplica as adaptações do pacote de host incorporado. Um comando de compilação genérico direto não representa o mesmo procedimento de construção. O diretório de artefato padrão é apps/desktop/src-tauri/target/release-artifacts.

O resources cópias passo packages/db/drizzle/ em apps/desktop/src-tauri/resources/migrations/ e é seguro repetir. O artifacts gravação de etapas SHA256SUMS e RELEASE_NOTES.md, construído a partir dos commits desde a última tag. Aliases de etapa são aceitos por --only e --skip: deps, checks/test, sidecar, migrations, e notes/checksums/release. O roteiro nunca lê .env* arquivos ou imprime valores secretos.

IC e publicação

O fluxo de trabalho de liberação é executado para v* tags ou uma tag de versão existente selecionada manualmente no repositório não-fork. release-ref.ts verifica a tag e a versão do aplicativo e resolve o commit. Cada build cria uma versão da plataforma, como uma tag de versão com o sufixo macos-arm64 ou linux-x64. Somente após a publicação de todos os lançamentos da plataforma o índice de versão publica o arquivo mesclado latest.json.

stage-release.ts verifica os artefatos selecionados, relacionamentos de soma de verificação/assinatura e links de manifesto antes da publicação. Releases já publicados não são substituídos. A versão do índice é elegível para se tornar a mais recente para versões estáveis; os pré-lançamentos permanecem marcados como pré-lançamentos.

As compilações do atualizador exigem a chave privada de assinatura Tauri e a configuração de senha correspondente à chave pública em tauri.conf.json. a assinatura/autenticação de versão do macOS usa certificado Apple e configurações de conta; O Windows importa um certificado de assinatura e passa sua impressão digital para o empacotador. As entradas de assinatura de versão necessárias ausentes falham na compilação da versão. Configure-os por meio do armazenamento secreto de CI.

Um trabalho de lançamento separado publica o pacote do plugin nikcli quando um token npm está disponível. Ele ignora uma versão já publicada e pode usar o nome do pacote substituto configurado quando o escopo primário não puder ser publicado. Este trabalho de pacote não estabelece a disponibilidade do instalador de desktop.

Comportamento do atualizador

O endpoint do atualizador configurado é o download da versão GitHub mais recente do repositório em latest.json. O atualizador Rust verifica no lançamento e a cada quatro horas, com verificações manuais enfileiradas em seu serviço. Cada solicitação usa um tempo limite de 30 segundos. O manifesto identifica ativos e assinaturas específicas da plataforma; a chave pública faz parte da configuração do aplicativo.

update://status carrega estados de verificação, atualizado, disponível, download, pronto e com falha. Notas de lançamento contendo [critical] marque a atualização disponível como não dispensável. Um estado pronto para reiniciar também não é dispensável. Isso afeta o prompt; a instalação ainda respeita a proteção de trabalho não salvo.

install_update registra e verifica novamente a versão anunciada e, em seguida, baixa um pacote com assinatura verificada. O editor salva antes do download e novamente antes apply_update, protegendo as edições feitas durante o download. O trabalho não salvo bloqueia ambas as operações; salvamentos com falha retêm bytes verificados para nova tentativa. O status nativo é recuperado após a assinatura e as verificações não podem substituir o progresso ativo ou uma reinicialização pendente. O Windows drena o sidecar antes que seu instalador assuma o controle; outras plataformas oferecem reinicialização após a instalação.

Compatibilidade de banco de dados

Aplicativos empacotados abertos cadcamfun.db no diretório de dados do aplicativo. As migrações pendentes são aplicadas pela camada de banco de dados na inicialização usando as migrações incluídas no pacote. As atualizações de esquema e as atualizações binárias estão, portanto, relacionadas, embora sejam artefatos separados.

As notas de versão geradas comparam as árvores de migração rastreadas com a tag de versão anterior. Uma árvore alterada é relatada como insegura para downgrade; uma árvore inalterada é relatada como compatível com migração; o histórico indisponível é relatado como desconhecido. Esta comparação automatizada não valida todos os possíveis problemas de compatibilidade no nível do aplicativo.

Antes de substituir um binário por uma versão mais antiga, preserve os dados atuais e inspecione as notas de compatibilidade da versão. O código de migração direta não implica migrações reversas. Siga os procedimentos de backup e recuperação do banco de dados para o diretório de dados real.

Verificação de liberação

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

Os testes auxiliares validam o mapeamento de destino, requisitos de assinatura, nomenclatura de artefatos, manipulação de manifesto e regras de preparação. Uma simulação imprime operações planejadas sem compilar ou assinar. Não substitui um pacote nativo real, teste de download/instalação do atualizador, nem aceitação de dispositivo físico para o complemento.

Para uma versão operacional, retenha a tag/confirmação exata, o resultado do fluxo de trabalho, o instalador específico do destino e o ativo de atualização, os arquivos de soma de verificação/assinatura e o manifesto publicado. Valide se o aplicativo instalado inicia seu sidecar e migrações agrupadas e se o atualizador seleciona o ativo de plataforma pretendido.

Referência de alvo e ativo

O gerador requer exatamente um ativo por formato acima, seu adjacente .sig arquivo e notas de lançamento. Os nomes dos ativos usam um <triple>-- prefixo; nomes duplicados e assinaturas órfãs são recusados. O atualizador Tauri 2.13.1 seleciona o tipo de pacote instalado automaticamente; Linux usa pacotes Debian/RPM assinados sem AppImage.

Os manifestos mesclados devem concordar com a versão, data de publicação e notas. A publicação requer todas as dez chaves acima. As chaves básicas do Windows mantêm a compatibilidade do NSIS para clientes mais antigos; As chaves MSI preservam as instalações MSI. URLs devem usar HTTPS sem credenciais, consulta ou fragmento. O teste verifica cada prefixo de destino, sufixo de pacote, assinatura e URL de lançamento.

Opções de construção local e entradas de assinatura

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

Remover --dry-run somente quando a cadeia de ferramentas de destino selecionada e os pré-requisitos nativos estiverem instalados. A compilação cruzada do executável Bun não fornece, por si só, um vinculador e empacotador Tauri de plataforma cruzada. --only e --skip são mutuamente exclusivos; --skip-install é um apelido de conveniência. --no-updater omite a criação de arquivo/assinatura do atualizador e seu portão de assinatura.

A compilação carrega credenciais do atualizador local apenas para a etapa de empacotamento e passa valores de assinatura por meio do ambiente para esse processo filho. Não imprima arquivos de assinatura local nem coloque material chave real em um exemplo de documentação. Uma chave privada que não corresponda à chave pública de um aplicativo instalado não pode produzir uma atualização aceita para esse aplicativo.

Diagnóstico de falha de liberação

Um relatório de lançamento útil registra qual estágio falhou e qual alvo ele estava construindo. Inclua nomes de artefatos não secretos, erros de validação e identificadores de fluxo de trabalho. Mantenha a versão anterior instalada e um backup de dados verificado disponível durante um exercício de atualização; a compatibilidade da migração é verificada separadamente da validade da assinatura.

Âncoras de implementação: scripts/release-helpers.ts, signing-config.ts, updater-manifest.ts, stage-release.ts, e apps/desktop/src-tauri/src/updater.rs.

As seis etapas de construção

As etapas sempre são executadas nesta ordem e uma etapa com falha interrompe a execução. O roteiro nunca lê .env arquivos e nunca imprime valores secretos.

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

A assinatura do atualizador local usa um ignorado tauri-signing.json quando nenhuma chave de assinatura está definida no ambiente. Os certificados de plataforma ainda são necessários quando CADCAM_RELEASE=1.

Matriz de lançamento

1. Um trabalho confiável valida a tag de lançamento em relação à versão do aplicativo.
2. Cada trabalho de matriz é executado bun --no-env-file scripts/build.ts --target=… --bundles=… --out-dir=release, assina e cria um manifesto para seus formatos de pacote. O Windows importa e depois remove seu certificado de assinatura opcional.
3. Uma tarefa de mesclagem valida todos os seis manifestos de arquitetura e suas dez entradas de pacote em um latest.json.
4. Um trabalho de conclusão verifica todos os artefatos, assinaturas, somas de verificação e notas do instalador antes de criar ou retomar o lançamento da versão única e publicá-la.

CI em cada push executa dois trabalhos: instalação, verificação de tipo e teste (e prepara o binário sidecar e as migrações) e um trabalho Rust com clippy e o src-tauri testes.

Em 3D