lizard redeploy
現在の変数を使用して新しいビルド(最新のコミット / 最後のアップロード)を開始します。
使い方
lizard redeploy [nameOrId] [flags]フラグ
| フラグ | 説明 |
|---|---|
-s, --service <name> | サービス |
--detach | ビルドが受け付けられたら戻る |
--wait | ビルドとデプロイの準備完了を待機します。--json と一緒に動作します |
--timeout <seconds> | ビルド後の準備完了待機時間の上限。デフォルトは 120 |
--json | スクリプト用に JSON を返します |
例
サービスを再ビルドして再デプロイする
lizard redeploy --service apiログをストリーミングせずに再デプロイする
lizard redeploy --service api --detachスクリプト内で待機する
CLI 0.3.94 以降が必要です。HTTP を使わない worker では 0.3.95 以降を使用してください。
lizard --json redeploy --service api --wait --timeout 120--wait がない場合、JSON モードはビルドリクエストが受け付けられた時点で返ります。--wait がある場合、CLI はそのビルドを追跡し、その後デプロイの準備完了を待機します。JSON の結果には buildId、ok、status が含まれます。ビルドの失敗、準備完了チェックの失敗、またはタイムアウトでは、非ゼロの終了コードが返されます。
タイムアウトはビルド完了後の準備完了に適用されます。ビルド時間を制限したり、デプロイをキャンセルしたりはしません。containerPort=0 を持つ worker は、HTTP チェックなしでバックエンドの準備完了ステータスを使用します。コマンドが正常に完了した後は、ワークフローでアプリケーションの動作確認が必要な場合、アプリケーションのエンドポイントまたは保存済みデータを確認してください。
関連項目
- lizard restart — 現在のビルドをローリング再起動、再ビルドなし
- lizard up — 現在のディレクトリをアップロードしてデプロイします
- デプロイメント — デプロイ、再起動、再ビルドの仕組み