# Meine Änderung hat zwei Builds direkt hintereinander in die Warteschlange gestellt Du hast `lizard service set` ausgeführt, um ein Feld zu ändern, dann `lizard redeploy`, und am Ende wurden zwei Builds statt nur eines gestartet. ## Was das bedeutet Der Aufruf `service set` hat bereits selbstständig einen Rebuild ausgelöst. Das anschließende `redeploy` hat einen zweiten, überflüssigen Build in die Warteschlange gestellt. ## Warum das passieren kann Wenn du ein **build-relevantes** Feld eines Service änderst — `repoUrl`, `branch`, `sourceType`, `buildCommand`, `dockerfilePath` oder `rootDirectory` — wird sofort automatisch ein Rebuild ausgelöst. Wenn du ein **reines Laufzeitfeld** änderst — `startCommand`, `preDeployCommand`, `containerPort`, `watchPatterns` — wird **kein** automatischer Rebuild ausgelöst; die Änderung wird erst beim nächsten Bereitstellen wirksam. Es ist leicht, reflexartig nach jedem `service set` noch ein `redeploy` anzuhängen, aber das ist nur bei reinen Laufzeitfeldern sinnvoll. ## Mögliche Lösungen ### Prüfe, welche Art von Feld du geändert hast Sieh in der [Tabelle der Rebuild-Auslöser](https://lizard.build/de/docs/concepts/build-pipeline#what-triggers-a-rebuild) nach. Wenn es ein Build-Feld ist, ist der Rebuild bereits in der Warteschlange — du musst nichts weiter tun. ```bash lizard events # confirm only one build is in flight ``` ### Nur nach Änderungen an reinen Laufzeitfeldern neu deployen ```bash lizard service set api --set startCommand="node server.js" lizard redeploy --service api # needed here — startCommand doesn't auto-rebuild ``` ## Siehe auch - [Build-Pipeline → was einen Rebuild auslöst](https://lizard.build/de/docs/concepts/build-pipeline#what-triggers-a-rebuild) - [`lizard service`](https://lizard.build/de/docs/cli/service) — die vollständige Befehlsreferenz.