Orbit
Azure DevOps リポジトリの接続
Orbit deploys from Azure Repos, the git hosting inside Azure DevOps. Connect once, pick a repository, and every push builds and goes live. This guide covers both ways to connect, selecting a…
Orbitは、Azure DevOps内のgitホスティングであるAzure Reposからデプロイします。一度接続すればリポジトリを選択でき、その後のすべてのプッシュがビルドされてライブになります。このガイドでは、両方の接続方法、リポジトリの選択、およびAzureが他のプロバイダと異なる2つの点について説明しています。
2つの接続方法とその理由
Azure DevOpsの組織はテナントレベルでサードパーティアプリケーションをブロックでき、多くの企業がそうしています。お客様の組織がそうしている場合は、サインインボタンがどうしても機能しないため、Orbitは常に機能する別の方法を提供しています。
- Microsoftでサインイン。 ワンクリック、コピペなし。お客様の組織がサードパーティアプリケーションを許可している場合に利用できます。
- 個人用アクセストークン。 アプリケーションをブロックしている組織を含む、すべての組織で機能します。Azure DevOpsで作成した組織名とトークンを貼り付けます。
どちらの方法でも、まったく同じ機能にアクセスできます。どちらも機能が制限されたバージョンではありません。
開始する前に
Orbitが見えるのは、お客様のAzure DevOpsアカウントが見えるものだけです。サービスフックの登録を作成するため、リポジトリに対して十分な権限が必要です。その登録がプッシュが当社に到達する方法だからです。これがないと接続には成功しますが、デプロイは一度も行われません。
オプションA: Microsoftでサインイン
- KPanelで、左側のサイドバーのOrbitをクリックします。
- 新規プロジェクトをクリックします。
- モードをImport Git Repoのままにしておきます。
- Azure DevOpsタブを選択し、Connect Azure DevOpsをクリックします。
Microsoftにサインインしてアクセスを承認するために送信されます。承認するとKPanelに戻され、リポジトリが読み込まれます。
組織がアプリケーションをブロックしている場合、Microsoftが拒否し、KPanelに理由が表示されます。これは再試行では解決できません。下の個人用アクセストークンを使用するか、管理者にアプリケーションを許可するよう依頼してください。
オプションB: 個人用アクセストークン
まずAzure DevOpsでトークンを作成します。
- Azure DevOpsで、ユーザー設定、個人用アクセストークン、新規トークンを開きます。
- デプロイ元にする組織を選択します。
- 以下の3つのスコープを付与し、これ以上は付与しません:
- コード (読み取り) - Orbitがリポジトリをリストし、ビルド中のコミットをダウンロードできるようにします。
- コード (ステータス) - ビルド結果がコミットおよびプルリクエストに表示されるようにします。
- サービスフック (読み取りと書き込み) - Orbitがプッシュをサブスクライブできるようにします。
- トークンをコピーします。Azureは一度だけ表示します。
その後KPanelで:
- Orbit、新規プロジェクト、Azure DevOpsタブを開きます。
- 個人用アクセストークンで接続の下に、組織名を入力します。これはリポジトリアドレスの
dev.azure.comの直後の部分です。https://dev.azure.com/contoso/web-platform/_git/storefrontの場合、組織はcontosoです。 - トークンを貼り付けてConnect Azure DevOpsをクリックします。
Orbitはトークンを直ちに使用してリポジトリをリストします。拒否された場合、トークンをチェックするように求められるのではなく、どのスコープが不足しているかが通知されます。これは、リポジトリをリストできてもサービスフックを作成できないトークンが、きれいに接続されてから何もデプロイされないという形を避けるためです。
トークンは保存前に暗号化され、指定した組織に対してのみ使用されます。
リポジトリの選択
リポジトリはorganisation / project / repositoryという名前のリストとして表示されます。Azureのリポジトリは2つではなく3つの部分があります。これは、1つの組織内の2つのプロジェクトが同じ名前のリポジトリを保持できるためです。
使用したいものの横にある選択をクリックしてから、通常どおりプロジェクトを完了します。名前、フレームワーク、ビルド設定、環境変数を設定します。
リポジトリが見つからない場合
- 組織を確認してください。個人用アクセストークンは1つの組織に属しているため、別の組織のリポジトリは表示されません。その組織も接続してください。
- Azure DevOpsのリポジトリ自体のアクセス権を確認してください。
- リポジトリがAzureで無効になっていないか確認してください。Orbitはビルドできないため、無効なリポジトリをリストしません。
Azureが異なる2つのこと
これらは実際の違いであり、当社がまだ対応していないギャップではなく、どちらも後で発見されるのではなく、ここに記載されています。
モノレポのルートディレクトリはプッシュをスキップしない
他のプロバイダの場合、Orbitは各プッシュで変更されたファイルのリストを読み、モノレポプロジェクトはルートディレクトリの下に何も変更がないとビルドをスキップできます。Azureはそのリストを送信しません。 したがってOrbitは推測するのではなく、すべてのプッシュでビルドします。別の方法で推測するとサイレントにデプロイをスキップしてしまうためです。
ルートディレクトリ設定は、ビルドが実行される場所を決定します。どのプッシュがビルドするかをフィルターするわけではありません。
フォークからのプルリクエストはビルドされない
Orbitはプロジェクトのプレビュー環境変数を使用してプルリクエストプレビューをビルドします。これは自分のリポジトリからのプルリクエストの場合は安全で、フォークからの場合は安全ではありません。フォークはお客様のアカウントと何の関係もない人からの提案です。
GitHubでは、Orbitはフォークプレビューを提供できます。GitHubが提案されたコミットをお客様独自のリポジトリ内に公開するため、貢献者のコピーに対して認証する必要がないためです。Azureは同等のものを公開しないため、Orbitはフォークプルリクエストを拒否し、表示されることのないプレビューを残すのではなく、コミットでそのことを示します。
お客様独自のリポジトリ内のブランチからのプルリクエストは通常どおりビルドされます。
次の処理
本番ブランチにプッシュするとOrbitがビルドおよびデプロイします。ビルド結果はAzure DevOpsのコミットに投稿されるため、コミットとコミットが属するすべてのプルリクエストに表示され、ブランチポリシーでそれを要求できます。