GitHub Enterprise Importer
を使った Organization の移行について
GitHub Enterprise Cloud への移行には、GitHub.com のアカウント間での移行のほか、データ所在地が を採用している場合はエンタープライズの GHE.com のサブドメインへの移行も含まれます。
GitHub CLI または API を使って、移行を実行できます。
GitHub CLI を使うと移行プロセスが簡単になるので、ほとんどのお客様に推奨されます。 カスタマイズのニーズが高い熟練したお客様は、API を使って、GitHub Enterprise Importer との独自の統合を構築できます。
前提条件
- 移行の試験的実行を行い、そのすぐ後で運用環境の移行を完了することを強くお勧めします。 試験的実行の詳細については、「GitHub 製品間の移行に関する概要」を参照してください。
- 移行されるデータと、Importer の既知のサポート制限事項を理解していることを確認します。詳細については、「GitHub 製品間の移行について」を参照してください。
- 必須ではありませんが、運用環境の移行の間は作業を停止することをお勧めします。 Importer は差分移行をサポートしていないため、移行中に発生した変更は移行されません。 運用環境の移行の間に作業を停止しない場合は、これらの変更を手動で移行する必要があります。
- 移行元の Organization に関して、Organization 所有者であるか、移行者ロールが付与されている必要があります。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」をご覧ください。
- 移行先 Enterprise アカウントに関して、Enterprise 所有者である必要があります。
手順 0: GitHub GraphQL API を使う準備をする
GraphQL クエリを作成するには、独自のスクリプトを記述するか、Insomnia などの HTTP クライアントを使う必要があります。
認証方法など、GitHub GraphQL API の概要については、「GraphQLでの呼び出しの作成」を参照してください。
すべての GraphQL クエリを、移行先に送信します。 データ所在地付き GitHub Enterprise Cloud に移行する場合は、GHE.com のエンタープライズのサブドメインのエンドポイントにクエリを送信してください。
手順 1: 移行先の Enterprise ID を取得する
GitHub.com の Enterprise 所有者として、次のクエリを使用して、移行された Organization を所有する Enterprise アカウントの ID を返します。 Enterprise ID は、移行先を識別するために必要です。
query(
$slug: String!
){
enterprise (slug: $slug)
{
slug
id
}
}
クエリ変数 | 説明 |
---|---|
slug | Enterprise アカウントのスラッグ。エンタープライズの URL (https:/ または https:/ ) を調べることで識別できます。 |
手順 2: Organization の移行を開始する
移行を始めると、1 つの Organization とそれに付随するデータが、指定した移行先 Enterprise 内の新しい Organization に移行されます。
mutation startOrganizationMigration (
$sourceOrgUrl: URI!,
$targetOrgName: String!,
$targetEnterpriseId: ID!,
$sourceAccessToken: String!,
$targetAccessToken: String!
){
startOrganizationMigration( input: {
sourceOrgUrl: $sourceOrgUrl,
targetOrgName: $targetOrgName,
targetEnterpriseId: $targetEnterpriseId,
sourceAccessToken: $sourceAccessToken,
targetAccessToken: $targetAccessToken
}) {
orgMigration {
id
}
}
}
クエリ変数 | 説明 |
---|---|
sourceOrgUrl | 移行元 Organization の URL (例: https:/ )。 |
targetOrgName | 新しい Organization に付ける名前。 移行先プラットフォーム上の別の organization で共有することはできません。 |
target | 手順 2 で返された、新しい Organization の作成先となる Enterprise の ID。 |
sourceAccessToken | 移行元 Organization の personal access token (classic)。 詳細については、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。 |
targetAccessToken | 移行先 Enterprise の personal access token (classic)。 |
次のステップでは、startOrganizationMigration
ミューテーションから返された移行 ID を使って、移行の状態を調べます。
手順 3: 移行の状態を確認する
移行エラーを検出し、移行が行われていることを確認するには、getMigration
クエリを使用して、作成した (複数の) OrganizationMigration
のクエリを実行することで、移行の状態を確認できます。
このクエリにより、移行が queued
、in progress
、failed
、completed
のいずれであるかがわかる状態と、移行を待機しているリポジトリの数に関する情報が返されます。 移行が失敗した場合、Importer によってエラーの原因が示されます。
query (
$id: ID!
){
node( id: $id ) {
... on OrganizationMigration {
id
sourceOrgUrl
targetOrgName
state
failure_reason
remaining_repositories_count
total_repositories_count
}
}
}
クエリ変数 | 説明 |
---|---|
id | 移行の id 。 |
移行が完了したら、移行ログ リポジトリを確認することをお勧めします。 詳しくは、「GitHub Enterprise Importer の移行ログへのアクセス」をご覧ください。
最後に、Organization と移行されたリポジトリの健全性チェックを実行することをお勧めします。