Gitからサイトをデプロイする

Git Deployはリポジトリをサイトに接続し、選択したブランチへのプッシュごとにコードをクローンし、ビルドを実行し、結果を公開します。このガイドでは、初期接続、セットアップを完了するためのリポジトリ側の2つのステップ、デプロイ履歴の読み取り、およびNode.jsアプリがどのようにビルドされるかを決定するビルドパック検出について説明します。

Git Deployの場所

Websitesを開き、サイトをクリックし、サイトのタブストリップでAdvancedメニューを開き、Git Deployを選択します。関連する2つのページが同じメニューに表示されます。

• Deploys：このサイトの完全なデプロイ履歴。
• Buildpack：検出されたビルド戦略（Node.jsサイト上）。

Git Deployページは明確に説明しています。リポジトリを接続し、設定されたブランチへのプッシュごとにビルドとデプロイがトリガーされます。

リポジトリの接続

1. Providerを選択します：GitHub、GitLabまたはBitbucket。
2. Repository URLを入力します。SSH形式が必要です。例：git@github.com:user/repo.git。
3. Branchをデプロイするように設定します。フィールドはmainから始まります。
4. オプションでBuild commandを設定します。例：npm run build。
5. オプションでOutput directoryを設定します。例：dist、public、または.（既にビルドされているリポジトリの場合）。
6. Connect repoをクリックします。

リポジトリが既にそのままデプロイ可能な場合は、ビルドコマンドと出力ディレクトリを空のままにします。これは通常のPHPまたは静的サイトの一般的なケースです。

Advanced Scripts

Advancedを展開すると、2つの追加フィールドが表示されます。

• Pre-deploy script：ビルドの前に実行されます。
• Post-deploy script：デプロイの後に実行されます。

post-deployフックを使用して、新しいコードが配置された後に実行する必要があることに対応します。アプリケーションキャッシュのクリア、データベースマイグレーションの実行、ワーカーの再起動など。

プッシュ時の自動デプロイ

カードの下部にあるトグルは、プッシュがデプロイをトリガーするかどうかを制御します。オンの場合、設定されたブランチへのプッシュごとにデプロイがトリガーされます。オフの場合、デプロイはDeploy nowで手動でトリガーする場合にのみ実行されます。

リポジトリでのセットアップの完了

KPanelでリポジトリを接続することは、3つのステップの最初のステップにすぎません。デプロイが実行されるまで、ページにはComplete setup: 2 steps remainingというバナーと必要なすべてのものが表示されます。

ステップ2：デプロイキーを追加

Kapsuleはリポジトリをクローンするための読み取りアクセスが必要です。バナーには公開キーとCopy keyボタンが表示されます。

それをリポジトリのデプロイキーに貼り付けます。GitHubの場合、バナーは適切な設定ページに直接移動するAdd to GitHubショートカットを提供します。読み取りアクセスで十分です。書き込みアクセスは付与しないでください。

ステップ3：ウェブフックを追加

ウェブフックは、プッシュが発生したことをKapsuleに通知するものです。バナーには3つの値があります：

各値をリポジトリのウェブフック設定にコピーします。GitHubの場合は、Add webhook to GitHubショートカットがあります。コンテンツタイプをJSON（フォームエンコードされたデフォルトではなく）に設定してください。そうしないとペイロードが解析されません。

手動でのデプロイ

Git DeployページでDeploy nowをクリックしてコミットをプッシュせずに、設定されたブランチの現在のヘッドをビルドしてデプロイします。これは自動デプロイがオンであるかどうかに関わらず機能します。これが凍結中に適切なツールである理由です。プッシュは無視されますが、それでも修正を発送できます。

デプロイ履歴の読み取り

Advancedを開き、次にDeploysを開きます。ページはDeploy historyという題名で、ウェブフックまたは手動でトリガーされたすべてのデプロイをリストします。最新のものが最初です。

各行には以下の情報があります：

• ステータスアイコンと短いコミットSHA（ブランチはピル形式）。
• コミットメッセージ、またはコミットメッセージを表示するものがない場合はManual deploy。
• 作成者、実行した時間、所要時間、およびトリガーしたもの。
• ステータスピル。

ステータスはpending、building、deploying、success、failedです。何かが進行中の場合、ページは5秒ごとに自動更新されることを示すRefreshing automaticallyノートがテーブルの下に表示されるため、ページを開いたままにしてデプロイが着地するのを見守ることができます。

デプロイが失敗した場合

失敗した行の右側にはErrorボタンがあります。クリックしてページを離れることなくキャプチャされたエラー出力を展開します。その出力はビルド自体のエラーテキストであるため、通常は失敗したファイルまたはコマンドの名前が表示されます。

この順序で処理を進めてください：エラーを読む、ローカルで同じビルドコマンドを実行する、修正する、プッシュする。ビルドがローカルではなくここで機能しない場合、違いはほぼ常に環境のものです。グローバルにマシンにインストールされている欠落している依存関係、またはワーキングディレクトリにはあるがコミットされていないファイル。

ビルドパック検出

Node.jsサイトでは、AdvancedメニューのBuildpackページに、Kapsuleがアプリをビルドする方法をどのように決定したかが表示されます。検出はリポジトリのルートにあるファイル上で実行され、最初のマッチが勝ちます：

何も一致しない場合、ページはそう表示され、サポートされているトリガーをリストします。ビルドを明示的に制御するためにDockerfileまたはkapsule.config.yamlを追加してください。

ビルドの実行

Run buildをクリックしてキューに入れます。実行が進行中にページは3秒ごとにポーリングされ、Recent buildsテーブルは開始時刻、種類、ステータス、期間、および結果のイメージリファレンスを含む最後の実行を表示します。行をクリックしてログテールを表示します。

同時に進行中のビルドは1つだけです。1つがキューまたは実行中の間に2番目をトリガーすると、A build is already in progressで拒否されます。これは意図的なものです。2つのビルドが同時に同じ出力に書き込むことは、半分デプロイされたサイトを得る方法です。

切断

Disconnectをクリックして確認します。確認は影響範囲について明示的です。Gitデプロイ設定とデプロイキーが削除され、サイトファイルは影響を受けません。サイトは最後にデプロイされたものを継続して提供します。

その後、リポジトリ設定のデプロイキーとウェブフックを削除してクリーンアップします。単に機能しなくなりますが、死んだエントリを残しておくと、次の監査がより困難になります。

トラブルシューティング

プッシュが何もトリガーしません。 まず自動デプロイトグルを確認し、次にリポジトリのウェブフックを確認します。ほとんどのプロバイダーは最近の配信とそのレスポンスコードを表示します。これにより、リクエストがリポジトリを離れたかどうかを即座に知ることができます。

クローンが失敗します。 デプロイキーが欠落している、改行が挿入されてコピーされた、または間違ったリポジトリに追加されました。手動でテキストを選択するのではなく、Copy keyボタンを使用して再度コピーしてください。

デプロイは成功しますが、サイトが変わりません。 出力ディレクトリが間違っている可能性があります。ビルドがdistに書き込み、出力ディレクトリが空の場合、ビルドされたファイルは提供されるルートに到達しません。

すべてがpendingと言い、移動しません。 デプロイはキューに入れられましたが、ピックアップされませんでした。手動でDeploy nowをトリガーし、Deploysページでエラー行を確認します。

次のステップ

• Preview Deploys For Pull Requestsはこのセットアップの上に、PR当たりのURLを追加します。
• Storing App Secrets For a Siteビルドとランタイムが必要とする認証情報のために。
• Site Activity Logここで加えられた設定変更を記録します。