# 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](https://lizard.build/es/docs/concepts/build-pipeline#what-triggers-a-rebuild). Si es un campo de build, la reconstrucción ya está en cola; no hagas nada más. ```bash lizard events # confirm only one build is in flight ``` ### Solo vuelve a desplegar después de cambios solo de runtime ```bash 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](https://lizard.build/es/docs/concepts/build-pipeline#what-triggers-a-rebuild) - [`lizard service`](https://lizard.build/es/docs/cli/service) — la referencia completa de comandos.