Mi cambio puso en cola dos builds seguidos

Ejecutaste lizard service set para cambiar un campo, luego lizard redeploy, y terminaste con dos builds en lugar de uno.

Qué significa esto

La llamada service set ya activó una reconstrucción por sí sola. El redeploy posterior puso en cola una segunda reconstrucción redundante.

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. 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, la reconstrucción ya está en cola; no hagas nada más.

lizard events   # confirm only one build is in flight

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-rebuild

Ver también

• Pipeline de build → qué activa una reconstrucción
• lizard service — la referencia completa de comandos.