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 nach. Wenn es ein Build-Feld ist, ist der Rebuild bereits in der Warteschlange — du musst nichts weiter tun.

lizard events   # confirm only one build is in flight

Nur nach Änderungen an reinen Laufzeitfeldern neu deployen

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
• lizard service — die vollständige Befehlsreferenz.