コードホストを接続

Control Center は 3 つのコードホストに対応しています。アプリ全体ではこれらをフォージと呼びます: GitHub、GitLab、Bitbucket Cloud です。どれも既定ではありません。1 つ接続すればすべてが機能し、複数接続すれば 1 つのワークスペースでそれらすべてのリポジトリを同時に保持できます。

コードホストは各リポジトリのプロパティであり、登録時にその origin リモートから読み取られます。自分で選ぶことはなく、ワークスペースごとに設定を間違える余地もありません。

コードホストを接続

設定 → ワークスペース → プロフィールと識別情報を開きます（/settings/workspace/profile）。
コードホスティングカードを探します。対応するコードホストは接続の有無にかかわらずすべて一覧表示されます。
行に …でサインイン があればそれを押し、なければ トークンを追加 を押してトークンを貼り付けます。

サインイン が表示されるのは、サーバーにアプリが登録されているコードホストです。現在は GitHub で、デバイスフローを使用します（GitHub App を作成を参照）。それ以外はトークンの貼り付けになります。これは、完了できないボタンを見せるよりも正直な操作です。

どちらの場合も、資格情報はあなたのものでありサーバー上に存在し、ユーザー ID をキーとして管理されます。入力したマシンにはトークンは保存されず、サインインしたすべてのデバイスが同じものを使い、他のメンバーが読み取ることもできません。反映されるのは次のリクエストからで、再起動するものは何もなく、切断すれば送信は即座に止まります。

各行にはその資格情報の出どころが表示されます。「自分のトークンが動かない」のか「別のトークンが応答している」のかを分けるのは、そこだからです:

サブタイトル	意味
`octocat としてサインインしています`	あなた自身の資格情報が使われています
`octocat としてサインインしています · このサーバーのアプリ経由`	サーバーのアプリのアイデンティティが応答しています — あなたはサインインしていません
`octocat としてサインインしています · 環境変数から`	サーバーの環境変数が応答しており、あなたの資格情報ではありません
`未接続`	このコードホストに対する資格情報がありません

各コードホストに必要なトークン

コードホスト	トークン	作成場所
GitHub	クラシック: `repo` と `read:org`。きめ細かい: Contents + Pull requests (read/write)、Checks + Actions (read)	github.com → Settings → Developer settings → Tokens
GitLab	`api` を持つパーソナルアクセストークン	gitlab.com → User settings → Access tokens
Bitbucket	Atlassian の API トークンと、アカウントのメールアドレス	id.atlassian.com → Security → API tokens

Bitbucket はアカウントのメールアドレスをユーザー名として、トークンをパスワードとして認証します。トークンと組み合わせるメールアドレスをサーバーが判別できるよう、サーバーの環境に BITBUCKET_EMAIL を設定します。

環境変数を使う場合

ヘッドレス環境または CI へのインストールでは、サーバーは次のものを読み取ります:

GitHub — GITHUB_TOKEN、次に GH_TOKEN
GitLab — GITLAB_TOKEN、次に CI_JOB_TOKEN
Bitbucket — BITBUCKET_API_TOKEN、次に BITBUCKET_TOKEN（BITBUCKET_EMAIL と併用）

これらはあなたのものではなくサーバーの資格情報であり、この区別は重要です。あなたの代理で行われるリクエストはあなたの資格情報だけを使うため、環境が黙ってあなたの代わりになることはありません。人の介在しない処理 — Webhook、PR のポーリング、チケット同期 — は、まずサーバーのアプリのアイデンティティを、次にサーバー所有者の資格情報を、最後に環境を解決します。この順序は固定されているため、「サインインしたのに何も変わらなかった」がサポートされる結果になることはありません。

コードホストごとに別人になる

同じ人間でも、GitHub では octocat、GitLab ではまったく別の名前になります。Control Center はあなたのアイデンティティをコードホストごとに解決し、リポジトリごとに適切なものを使用します。これにより、混在したワークスペースでも「自分のレビューが必要」「自分が作成」「あなたが承認済み」が正しくなります。

コードホストのアイデンティティが解決されていない場合、そのリポジトリは受信トレイに何も寄与しません（すべてに一致させることはしません）。受信トレイは、あなたがすべて確認済みだと主張する代わりに、その旨を表示します。

1 つの受信トレイ、すべてのコードホスト

受信トレイと PR キューは、ワークスペースに存在するすべてのコードホストにファンアウトし、結果を 1 つのストリームに統合します。GitHub のプルリクエストと Bitbucket のプルリクエストは、ベンダーごとにまとめられるのではなく時間順に並び、隣り合って表示されます。

障害は隔離されます。ダウンしている、レート制限中、または未接続のコードホストは何も寄与せず、他のコードホストには影響しません。受信トレイ全体が空になることはありません。そのコードホスト自身のリポジトリは、復旧するまで最後に判明した状態を表示し続けます。

各コードホストにできること

どのコードホストも基本のループはサポートしています。プルリクエストの一覧表示とオープン、差分の読み取り、インラインおよびトップレベルでのコメント、レビュー、マージ、クローズです。それ以外の部分は本当に異なっており、Control Center は、黙って失敗する操作を表示するのではなく、そのコードホストにできないことを非表示にします。

機能	GitHub	GitLab	Bitbucket
一括（保留中）レビュー	✓	✓	—
変更をリクエスト	✓	✓	✓
ファイルごとの「閲覧済み」状態の同期	✓	—	—
絵文字リアクション	✓	✓	—
チーム / グループのレビュアー	✓	✓	—
レビュアーの提案	✓	—	✓
PR の CI 結果	✓	✓	✓
CI ジョブのステップ/ログの詳細表示	✓	✓	—
スタックされたプルリクエスト	✓	—	—
PR 説明テンプレート	✓	✓	—
通知のポーリング	✓	—	—
リッチなユーザープロフィール	✓	✓	—
サーバー側の PR head ref	✓	✓	—

機能が欠けている場合、その機能は正直に縮退します:

閲覧済み状態は引き続き機能しますが、設定したデバイス上でのみです。
Bitbucket の一括レビューはコメントを 1 件ずつ投稿するため、レビュアーにはまとめてではなく個別に届きます。
Bitbucket にはPR head ref がないため、プルリクエストをチェックアウトするとソースブランチを名前で取得します。これはそのブランチが削除されると失敗します。

用語

GitLab はプルリクエストをマージリクエストと呼びます。Control Center は自身のモデル全体では「プルリクエスト」と呼び、コードホストについて述べるときは各コードホスト自身の呼び方を使います。

トラブルシューティング

PR 一覧が空で、コードホストが未接続と表示される

そのコードホストの資格情報がありません。設定 → ワークスペース → プロフィールと識別情報 → コードホスティングでサインインするか、トークンを貼り付けてください。他のコードホストのリポジトリには影響しません。