El CLI en integración continua
Lo que cambia cuando el que ejecuta el CLI es una máquina: la matriz de sistemas, qué guardar en caché para que no tarde una eternidad, los secretos que necesita cada plataforma, y el trabajo rápido que caza la mayoría de los fallos.
Dos trabajos, no uno
El error de montaje más común es tener un único trabajo que compila y empaqueta las tres plataformas en cada cambio. Es lento, caro, y el noventa por ciento de las veces no hace falta.
La compilación sin empaquetar en las tres plataformas es la pieza clave del trabajo rápido: es lo que hace cumplir la regla del nivel 3.3 —probar en los tres desde la primera semana— sin pagar el precio de generar instaladores en cada cambio.
La caché, que es lo que decide el tiempo
Sin caché, cada ejecución compila el árbol de dependencias entero, que son los minutos del nivel 5.3, en las tres plataformas, cada vez.
Lo que hay que guardar:
| qué | por qué |
|---|---|
src-tauri/target/ |
los artefactos de Cargo. Es el que ahorra el tiempo de verdad |
| el registro de Cargo | los paquetes descargados, para no volver a bajarlos |
| las dependencias del frontend | lo mismo, del otro lado |
Y las dos reglas que hacen que la caché sirva de algo:
- La clave incluye el sistema operativo y el fichero de bloqueo. Una caché compartida entre plataformas no vale, y una que no se invalide al cambiar dependencias sirve artefactos viejos.
- La caché de la rama principal se comparte con las ramas nuevas. Si no, cada rama empieza de cero y la caché no ayuda a quien más la necesita.
Los secretos, por plataforma
Cada sistema pide lo suyo, y solo en el trabajo de publicación:
| plataforma | qué necesita |
|---|---|
| macOS | el certificado de desarrollador y su contraseña, y las credenciales de notarización |
| Windows | el certificado o el acceso al servicio de firma en la nube |
| todas | la clave privada del updater y su contraseña, si publicas actualizaciones |
Tres reglas que valen para los tres:
- Como secretos cifrados del sistema de integración, nunca como ficheros del repositorio. Nivel 6.5.
- Solo en el trabajo que los necesita. Un trabajo de verificación no debería tener acceso a la clave de firma: si un cambio malicioso llega a ejecutarse ahí, no puede llegar a ella.
- Y no en trabajos que se disparen desde una contribución externa. Es la vía por la que se filtran los secretos de un proyecto abierto.
Los tres fallos que solo aparecen ahí
La máquina está limpia. No tiene tu cadena de herramientas, ni tus dependencias del sistema, ni la caché que llevas meses acumulando. Un proyecto que compila en tu portátil y no en la máquina de integración casi siempre depende de algo que instalaste hace meses y olvidaste. En Linux, la lista del nivel 5.1 hay que instalarla explícitamente.
Nadie contesta a un diálogo. Cualquier cosa que pida confirmación se queda esperando hasta que el trabajo expira. El caso típico es el llavero de macOS pidiendo permiso para usar el certificado, que se resuelve creando un llavero temporal para el trabajo y desbloqueándolo sin interacción.
El reloj y la red. La notarización depende de un servicio externo que a veces tarda, y el sellado de tiempo de la firma de Windows también. Un fallo intermitente en la publicación suele ser eso y no tu proyecto, así que conviene reintentar antes de investigar.