CLI-Referenzredeploy

lizard redeploy

Löst einen frischen Build aus (neuester Commit / letzter Upload) mit den aktuellen Variablen.

Verwendung

lizard redeploy [nameOrId] [flags]

Flags

FlagBeschreibung
-s, --service <name>Service
--detachGibt zurück, nachdem der Build akzeptiert wurde
--waitWartet auf den Build und die Bereitstellung der Deployment-Readiness; funktioniert mit --json
--timeout <seconds>Zeitbudget für das Warten auf Readiness nach dem Build; Standard 120
--jsonGibt JSON für Skripte zurück

Beispiele

Service neu bauen und erneut deployen

lizard redeploy --service api

Erneut deployen, ohne Logs zu streamen

lizard redeploy --service api --detach

In einem Skript warten

Erfordert CLI 0.3.94 oder neuer. Verwende 0.3.95 oder neuer für Worker ohne HTTP.

lizard --json redeploy --service api --wait --timeout 120

Ohne --wait gibt der JSON-Modus zurück, nachdem die Build-Anfrage akzeptiert wurde. Mit --wait verfolgt die CLI diesen Build und wartet dann auf die Deployment-Readiness. Das JSON-Ergebnis enthält buildId, ok und status. Ein fehlgeschlagener Build, eine fehlgeschlagene Readiness-Prüfung oder ein Timeout liefern einen Exit-Code ungleich null zurück.

Das Timeout gilt für die Readiness, nachdem der Build abgeschlossen ist; es begrenzt nicht die Build-Dauer und bricht das Deployment nicht ab. Worker mit containerPort=0 verwenden den Readiness-Status aus dem Backend ohne HTTP-Prüfung. Prüfe nach einem erfolgreichen Befehl einen Anwendungsendpunkt oder gespeicherte Daten, wenn dein Workflow das Anwendungsverhalten verifizieren muss.

Siehe auch

  • lizard restart — Rolling-Restart des aktuellen Builds, kein Neubau
  • lizard up — lädt das aktuelle Verzeichnis hoch und deployt es
  • Bereitstellungen — wie Deploys, Neustarts und Rebuilds funktionieren
uprestart