Mi redeploy canceló el build que había iniciado mi cambio
Ejecutaste lizard service set para cambiar un campo y luego lizard redeploy. El despliegue tardó más de lo esperado, y el historial puede mostrar un build cancelado.
Qué significa esto
La llamada service set ya inició una reconstrucción por sí sola. El redeploy posterior canceló ese build, cuyo log termina con --- Build cancelled: a newer deploy was triggered ---, y volvió a empezar el mismo build desde el principio.
Por qué puede pasar esto
Cambiar un campo que afecta al build en un servicio — repoUrl, branch, sourceType, buildCommand, dockerfilePath o rootDirectory — activa una reconstrucción automática de inmediato en un servicio en ejecución. Un servicio que ha fallado o que nunca se ha desplegado no se reconstruye por sí solo. Cambiar un campo solo de runtime — startCommand, preDeployCommand, containerPort, watchPatterns — no activa una reconstrucción automática; solo surte efecto en el siguiente deploy.
Es fácil encadenar por reflejo un redeploy después de cada service set, pero eso solo tiene sentido para los campos solo de runtime.
Posibles soluciones
Comprueba qué tipo de campo cambiaste
Consulta la tabla de activadores de reconstrucción. Si es un campo de build y el servicio estaba en ejecución, la reconstrucción ya empezó; no hagas nada más. Si el servicio había fallado o nunca se había desplegado, ejecuta lizard redeploy una vez.
lizard events # is a build already running?Solo vuelve a desplegar después de cambios solo de runtime
lizard service set api --set startCommand="node server.js"
lizard redeploy --service api # needed here — startCommand doesn't auto-rebuildVer también
- Pipeline de build → qué activa una reconstrucción
lizard service— la referencia completa de comandos.
Actualizado