Construcciones y lanzamientos

Modelo de distribución

La compilación de escritorio incluye una interfaz Vite, un sidecar compilado por Bun y migraciones SQLite generadas en una aplicación Tauri. El repositorio define las compilaciones de macOS Apple Silicon e Intel, Windows x64 y ARM64, y Linux x64 y ARM64. La automatización de lanzamiento está configurada en .github/workflows/release.yml; las comprobaciones de compilación de la plataforma también se ejecutan de forma independiente a través de build-platforms.yml.

Una definición de flujo de trabajo describe el proceso de publicación. La disponibilidad y validez de un instalador debe establecerse a partir de sus activos de ejecución y liberación particulares. El código fuente por sí solo no prueba las credenciales de firma, los resultados de la certificación notarial o la instalación exitosa en una máquina de destino.

Construir canalización

scripts/build.ts ejecuta seis etapas ordenadas y aborta cuando falla una etapa:

1. Instalar: instalación de frozen-lockfile, incluidas dependencias opcionales para todos los sistemas operativos y arquitecturas de CPU.
2. Controlar: comprobación de tipo de espacio de trabajo. Las pruebas unitarias son un comando CI independiente.
3. Compilar: construir el sidecar con scripts/compile-sidecar.ts para el triple objetivo de Rust.
4. Recursos: escenario packages/db/drizzle como migraciones agrupadas.
5. Manojo: cree la interfaz y luego invoque a Tauri con la configuración de destino, paquete, firma y actualización.
6. Artefactos: indexe los recursos del instalador, escriba sumas de verificación SHA-256 y genere notas de la versión a partir del historial de 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 y --skip aceptar nombres artísticos; --target, --bundles, y --out-dir seleccionar salidas. El objetivo predeterminado es el host informado por rustc -vV. Los binarios sidecar están escritos en apps/desktop/src-tauri/binaries/sidecar-<triple>, con .exe en Windows. Los binarios idénticos y los árboles de migración se mantienen sin cambios para evitar reinicios innecesarios del desarrollo.

Usar compile-sidecar.ts a través de la canalización: aplica las adaptaciones de agrupación de host integrado. Un comando de compilación genérico directo no representa el mismo procedimiento de compilación. El directorio de artefactos predeterminado es apps/desktop/src-tauri/target/release-artifacts.

El resources copias paso a paso packages/db/drizzle/ en apps/desktop/src-tauri/resources/migrations/ y es seguro repetirlo. El artifacts paso escribe SHA256SUMS y RELEASE_NOTES.md, creado a partir de las confirmaciones desde la última etiqueta. Los alias de pasos son aceptados por --only y --skip: deps, checks/test, sidecar, migrations, y notes/checksums/release. El guión nunca se lee. .env* archivos o imprime valores secretos.

CI y publicación

El flujo de trabajo de lanzamiento se ejecuta durante v* etiquetas o una etiqueta de versión existente seleccionada manualmente en el repositorio no bifurcado. release-ref.ts comprueba la etiqueta y la versión de la aplicación y resuelve la confirmación. Cada compilación crea una versión de plataforma, como una etiqueta de versión con el sufijo macos-arm64 o linux-x64. Sólo después de que se publiquen todas las versiones de la plataforma, el índice de versiones publica las versiones fusionadas. latest.json.

stage-release.ts comprueba los artefactos seleccionados, las relaciones de suma de comprobación/firma y los enlaces de manifiesto antes de la publicación. Las versiones ya publicadas no se sobrescriben. La versión del índice es elegible para convertirse en la más reciente para versiones estables; las presentaciones preliminares permanecen marcadas como presentaciones preliminares.

Las compilaciones del actualizador requieren la clave privada de firma de Tauri y la configuración de contraseña correspondiente a la clave pública en tauri.conf.json. la firma/notaría de lanzamiento de macOS utiliza el certificado de Apple y la configuración de la cuenta; Windows importa un certificado de firma y pasa su huella digital al paquete. Las entradas de firma de versión requeridas que faltan fallan en la compilación de la versión. Configúrelos a través del almacén secreto de CI.

Un trabajo de lanzamiento independiente publica el paquete del complemento nikcli cuando hay un token npm disponible. Omite una versión ya publicada y puede usar el nombre del paquete alternativo configurado cuando el alcance principal no se puede publicar. Este trabajo de paquete no establece la disponibilidad del instalador de escritorio.

Comportamiento del actualizador

El punto final del actualizador configurado es la descarga de la última versión de GitHub del repositorio en latest.json. El actualizador de Rust realiza comprobaciones en el momento del lanzamiento y cada cuatro horas, con comprobaciones manuales en cola a través de su servicio. Cada solicitud utiliza un tiempo de espera de 30 segundos. El manifiesto identifica firmas y activos específicos de la plataforma; la clave pública es parte de la configuración de la aplicación.

update://status lleva estados de verificación, actualizado, disponible, descargando, listo y fallido. Notas de la versión que contienen [critical] marque la actualización disponible como no descartable. Un estado listo para reiniciar tampoco es descartable. Esto afecta el mensaje; La instalación sigue respetando la protección contra trabajos no guardados.

install_update registra y vuelve a verificar la versión anunciada, luego descarga un paquete con firma verificada. El editor guarda antes de la descarga y nuevamente antes apply_update, protegiendo las ediciones realizadas durante la descarga. El trabajo no guardado bloquea ambas operaciones; Los guardados fallidos conservan los bytes verificados para volver a intentarlo. El estado nativo se recupera después de suscribirse y las comprobaciones no pueden reemplazar el progreso activo o un reinicio pendiente. Windows drena el sidecar antes de que su instalador tome el control; otras plataformas ofrecen un reinicio después de la instalación.

Compatibilidad de bases de datos

Aplicaciones empaquetadas abiertas cadcamfun.db en el directorio de datos de su aplicación. Las migraciones pendientes las aplica la capa de base de datos al inicio utilizando las migraciones incluidas en el paquete. Por lo tanto, las actualizaciones de esquemas y las actualizaciones binarias están relacionadas aunque sean artefactos separados.

Las notas de la versión generadas comparan los árboles de migración rastreados con la etiqueta de la versión anterior. Un árbol modificado se informa como no seguro para su degradación; un árbol sin cambios se informa como compatible con la migración; El historial no disponible se informa como desconocido. Esta comparación automatizada no valida todos los posibles problemas de compatibilidad a nivel de aplicación.

Antes de reemplazar un binario con una versión anterior, conserve los datos actuales e inspeccione las notas de compatibilidad de la versión. El código de migración hacia adelante no implica migraciones hacia atrás. Siga los procedimientos de copia de seguridad y recuperación de la base de datos para el directorio de datos real.

Verificación de liberación

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

Las pruebas auxiliares validan la asignación de objetivos, los requisitos de firma, la denominación de artefactos, el manejo de manifiestos y las reglas de preparación. Un ensayo imprime las operaciones planificadas sin compilar ni firmar. Ninguno de los dos sustituye a un paquete nativo real, ni a una prueba de descarga/instalación del actualizador, ni a la aceptación del dispositivo físico del complemento.

Para una versión operativa, conserve la etiqueta/compromiso exacto, el resultado del flujo de trabajo, el instalador específico del destino y el activo de actualización, los archivos de suma de comprobación/firma y el manifiesto publicado. Valide que la aplicación instalada inicie su sidecar incluido y sus migraciones y que el actualizador seleccione el recurso de plataforma deseado.

Referencia de objetivos y activos

El generador requiere exactamente un activo por formato anterior, su adyacente .sig archivo y notas de la versión. Los nombres de los activos utilizan un <triple>-- prefijo; Se rechazan nombres duplicados y firmas huérfanas. El actualizador de Tauri 2.13.1 selecciona el tipo de paquete instalado automáticamente; Linux utiliza paquetes Debian/RPM firmados sin AppImage.

Los manifiestos fusionados deben acordar la versión, la fecha de publicación y las notas. La publicación requiere las diez claves anteriores. Las claves básicas de Windows conservan la compatibilidad con NSIS para clientes más antiguos; Las claves MSI preservan las instalaciones MSI. Las URL deben utilizar HTTPS sin credenciales, una consulta o un fragmento. La preparación comprueba cada prefijo de destino, sufijo de paquete, firma y URL de lanzamiento.

Opciones de compilación local y entradas de 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

Eliminar --dry-run solo cuando la cadena de herramientas de destino seleccionada y los requisitos previos nativos están instalados. La compilación cruzada del ejecutable Bun no proporciona por sí sola un enlazador y empaquetador Tauri multiplataforma. --only y --skip son mutuamente excluyentes; --skip-install es un alias de conveniencia. --no-updater omite la creación de firma/archivo de actualización y su puerta de firma.

La compilación carga las credenciales del actualizador local solo para el paso de agrupación y pasa los valores de firma a través del entorno a ese proceso secundario. No imprima archivos de firma locales ni coloque material clave real en un ejemplo de documentación. Una clave privada que no coincide con la clave pública de una aplicación instalada no puede generar una actualización aceptada para esa aplicación.

Diagnóstico de fallo de liberación

Un informe de lanzamiento útil registra qué etapa falló y qué objetivo se estaba construyendo. Incluya nombres de artefactos no secretos, errores de validación e identificadores de flujo de trabajo. Mantenga la versión instalada anteriormente y una copia de seguridad de datos verificada disponibles durante un ejercicio de actualización; la compatibilidad de la migración se verifica por separado de la validez de la firma.

Anclas de implementación: scripts/release-helpers.ts, signing-config.ts, updater-manifest.ts, stage-release.ts, y apps/desktop/src-tauri/src/updater.rs.

Los seis pasos de construcción

Los pasos siempre se ejecutan en este orden y un paso fallido detiene la ejecución. El guión nunca se lee. .env archivos y 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

La firma del actualizador local utiliza un ignorado tauri-signing.json cuando no se establece ninguna clave de firma en el entorno. Los certificados de plataforma aún son necesarios cuando CADCAM_RELEASE=1.

Matriz de liberación

1. Un trabajo confiable valida la etiqueta de versión con la versión de la aplicación.
2. Cada trabajo de matriz se ejecuta bun --no-env-file scripts/build.ts --target=… --bundles=… --out-dir=release, firma y crea un manifiesto para sus formatos de paquete. Windows importa y luego elimina su certificado de firma opcional.
3. Un trabajo de fusión valida los seis manifiestos de arquitectura y sus diez entradas de paquete en uno latest.json.
4. Un trabajo de finalización verifica todos los artefactos, firmas, sumas de verificación y notas del instalador antes de crear o reanudar la versión única y publicarla.

En cada inserción, CI ejecuta dos trabajos: instalación, verificación de tipos y prueba (y organiza el binario del sidecar y las migraciones), y un trabajo de Rust con clippy y el src-tauri pruebas.

En 3D