GitLabリポジトリの接続

GitLab connects to Orbit through OAuth rather than an installed app: you authorise Kapsule once, Orbit lists the projects your GitLab account can reach, and it registers a webhook per repository so…

GitLabはOAuthを通じてOrbitに接続します。インストール済みアプリではなく、Kapsuleを一度認可するとOrbitはあなたのGitLabアカウントがアクセスできるプロジェクトを一覧表示し、リポジトリごとにwebhookを登録して、プッシュのたびにビルドをトリガーします。このガイドでは、接続、リポジトリの選択、GitLabパイプラインでのデプロイゲーティング、およびリポジトリが表示されない一般的な理由をカバーします。

開始前に

OrbitはあなたのアカウントがアクセスできるGitLabプロジェクトのみを表示できます。グループが所有するプロジェクトの場合、少なくともDeveloper権限が必要で、リポジトリ上にwebhookを作成できるだけの権限が必要です。GitLabインスタンスが外部webhookを制限している場合、その制限がここにも適用されます。

ステップ1: GitLabに接続

KPanelで、左サイドバーのOrbitをクリックします。
New projectをクリックします。
モードをImport Git Repoのままにします。
ステップ1で、Connect GitLabをクリックします。

GitLabに送られて、Kapsule Orbitアプリケーションを認可します。リクエストされたスコープを承認するとGitLabはあなたをKPanelに返し、リポジトリが読み込まれます。ステップ1にはJust connectedが表示されます。

接続に失敗した場合、KPanelは汎用メッセージではなくGitLabが返したエラーを表示します。再試行する前にそれを読んでください。スコープの拒否と期限切れの認可には異なる修正が必要です。

ステップ2: リポジトリを選択

アクセス可能なリポジトリはリストとして表示されます。希望するものの隣のSelectをクリックします。プライベートリポジトリにはPrivateバッジが付きます。Orbitはパブリックおよびプライベートリポジトリの両方をデプロイします。

リポジトリが見つからない場合

プロジェクトのあなたのロールを確認してください。Reporter権限では不十分です。少なくともDeveloper権限が必要です。
プロジェクトがグループに属する場合、あなたのメンバーシップがグループまたはプロジェクト自体にあることを確認してください。祖先グループのロールが制限されている場合はそれだけではありません。
ステップ1でReconnect GitLabをクリックしてOAuth フローを再実行します。これはトークンをリフレッシュし、プロジェクトリストを再読み込みします。

パネルにNo repos accessibleと表示される場合、OAuthグラントは通過しましたが何も返されませんでした。再接続して、削減されたセットではなくリポジトリスコープを承認したことを確認してください。

ステップ3: プロジェクトを設定

フィールド	機能
Project Name	KPanelでの表示名。例えば`my-app`
Deploy URL	`kaps.run`の下のサブドメイン。`my-app`は`my-app.kaps.run`になります

Create projectをクリックします。Orbitはリポジトリを複製し、最初のビルドをキューに入れ、プロジェクト概要ページに移動します。

Deploy URLスラッグは作成時に固定され、後で変更できません。別のアドレスで公開するには、代わりにカスタムドメインを添付してください。Adding a Custom Domain to Your Projectを参照してください。

自動デプロイ

Orbitはプロジェクト作成時にGitLabリポジトリ上にwebhookを登録します。その後:

本番ブランチへのプッシュは、本番デプロイメントをキューに入れます。
他のブランチへのプッシュはbranch-<branch-name>.kaps.runで独立したプレビューをビルドします（SettingsのRuntime下でBranch previewsが有効な場合）。Branch Preview Deployments in Orbitを参照してください。
ブランチを削除すると、そのプレビュー環境は一時停止され、ストレージは約1日以内に回収されます。

手動でwebhookを作成または維持する必要はありません。

GitLab CIパイプラインの待機

GitLab CIでテストを実行する場合、Orbitはパイプラインが成功するまでデプロイを保留できます。

プロジェクトを開いて、Settingsに進みます。
CI required checksを探します。
空でない値を入力して保存します。

GitLab上で、値自体はジョブ名と一致していません。空でない値は、Orbitに全体のパイプラインが成功するまで待つよう指示します。パイプラインの失敗はOrbitデプロイメントを自動的にキャンセルします。これは本番ブランチのプッシュトリガーデプロイメントにのみ適用されます。

ここが2つのプロバイダーの違う点です。GitHubは値を名前付きActionsジョブと照合します。GitLabは空でない値を「全体のパイプラインを待つ」として扱います。GitHubとGitLabプロジェクト間で設定をコピーしている場合、同じフィールドが同じように動作することを期待しないでください。

GitLabを再接続または切断

OrbitをクリックしてからNew projectをクリックします。
ステップ1で、OAuth フローを再実行するにはReconnectをクリックするか、リンクを削除するにはDisconnectをクリックします。

リポジトリリストが機能しなくなるたびに、Reconnectが最初の正しい手段です。OAuthトークンは期限切れになり、再接続すると新しいトークンが発行されます。

切断するとプロジェクトとそのデプロイメント履歴が保持され、ライブデプロイメントはトラフィックの提供を続けます。停止するのはプッシュトリガーのデプロイメントです。デプロイフックも機能しなくなります。フックが何をビルドするかを知るにはプロバイダー接続を通じてブランチヘッドを読む必要があるためです。