Mein Redeploy hat den Build abgebrochen, den meine Änderung gestartet hat
Du hast lizard service set ausgeführt, um ein Feld zu ändern, dann lizard redeploy. Der Deploy hat länger gedauert als erwartet, und der Verlauf zeigt womöglich einen abgebrochenen Build.
Was das bedeutet
Der Aufruf service set hat bereits selbstständig einen Rebuild gestartet. Das anschließende redeploy hat diesen Build abgebrochen, dessen Log mit --- Build cancelled: a newer deploy was triggered --- endet, und denselben Build von vorn gestartet.
Warum das passieren kann
Wenn du ein build-relevantes Feld eines Service änderst — repoUrl, branch, sourceType, buildCommand, dockerfilePath oder rootDirectory — wird ein laufender Service sofort automatisch neu gebaut. Ein abgestürzter oder noch nie bereitgestellter Service wird nicht selbstständig neu gebaut. 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 und der Service lief, ist der Rebuild bereits gestartet — du musst nichts weiter tun. Wenn der Service abgestürzt war oder noch nie bereitgestellt wurde, führe einmal lizard redeploy aus.
lizard events # is a build already running?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-rebuildSiehe auch
- Build-Pipeline → was einen Rebuild auslöst
lizard service— die vollständige Befehlsreferenz.
Aktualisiert