API を使用することを選んだ場合は、独自のスクリプトを記述するか、[Insomnia](https://insomnia.rest/) などの HTTP クライアントを使用する必要があります。 GitHub と [REST API を使用した作業の開始](/ja/enterprise-server@3.18/rest/using-the-rest-api/getting-started-with-the-rest-api) で、[](/ja/enterprise-server@3.18/graphql/guides/forming-calls-with-graphql) の API の利用を開始する方法について詳しく知ることができます。 API を使用してリポジトリを GitHub Enterprise Server から GitHub Enterprise Cloud に移行するには、次の手順を実行します。 1. ソース組織と移行先組織の両方の personal access token を作成する 2. `ownerId` 上の宛先組織の GitHub Enterprise Cloud を取得する 3. GitHubの GraphQL API を使用して移行ソースを設定し、移行元を特定する 4. 移行するリポジトリごとに、次の手順を繰り返します。 * お使いの GitHub Enterprise Server インスタンス上の REST API を使用して、リポジトリの移行アーカイブを生成する * 移行アーカイブをアクセスできる場所にアップロードする GitHub * 移行先の GraphQL API を使用して移行を開始し、アーカイブの URL を渡します * GraphQL API を使用して移行の状態を確認します * 移行を検証し、エラーログを確認します

API の使い方を確認するには、ページの上部にあるツールスイッチャーを使います。

GitHub CLI の使い方を確認するには、ページの上部にあるツールスイッチャーを使います。

## 手順 1. personal access tokenを作成します 1. personal access token (classic) 上の移行先 Organization に対して認証を行う GitHub Enterprise Cloud を作成して記録し、トークンがすべての要件を満たしていることを確認します。詳しくは、「[GitHub 製品間の移行のためのアクセスの管理](/ja/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#creating-a-personal-access-token-for-github-enterprise-importer)」をご覧ください。 2. 移行元 Organization に対して認証を行う personal access token を作成して記録し、このトークンも同じ要件をすべて満たしていることを確認します。 ## 手順 2: 移行先 Organization の `ownerId` を取得する GitHub Enterprise Cloud の Organization 所有者として、`GetOrgInfo` クエリを使って、移行されたリポジトリを所有する Organization の `ownerId` (Organization ID とも呼ばれます) を取得します。移行先を識別するには、`ownerId` が必要です。 #### `GetOrgInfo` クエリ ```graphql query( $login: String! ){ organization (login: $login) { login id name databaseId } } ``` | クエリ変数 | 説明 | | ------- | ----------------- | | `login` | Organization の名前。 | #### `GetOrgInfo` の応答 ```json { "data": { "organization": { "login": "Octo", "id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=", "name": "Octo-org", "databaseId": 5610 } } } ``` この例では、`MDEyOk9yZ2FuaXphdGlvbjU2MTA=` が Organization ID つまり `ownerId` であり、次のステップでそれを使います。 ## 手順 3: BLOB ストレージを設定するリポジトリの移行を実行するときは、 GitHub Enterprise Importer がアクセスできる場所にリポジトリデータを格納する必要があります。これは次の方法で実現できます。 * GHES インスタンス (GHES **3.16** 以降) 上でローカルストレージを使う * BLOB ストレージプロバイダーを使用する ### ローカルストレージ (GHES 3.16 以降) の使用ローカルストレージを使用して移行を実行すると、クラウドストレージプロバイダーを必要とせずに、お使いの GitHub Enterprise Server インスタンス上のディスクにアーカイブデータが書き込まれます。 * GitHub Enterprise Server からのエグレストラフィックをブロックするファイアウォール規則がない場合、GitHub Enterprise Importer は、GitHub Enterprise Server から格納されたアーカイブを自動的に取得できます。 * ファイアウォール規則が設定されていて、GitHub Enterprise Importer へのアクセスを許可したくない場合は、アーカイブデータを GitHub-owned blob storage にアップロードして、GitHub Enterprise Importer がアクセスできるようにすることができます。手動で行うには、この記事の API バージョンの「[移行アーカイブを GitHub 所有の BLOB ストレージにアップロードする](/ja/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/migrating-repositories-from-github-enterprise-server-to-github-enterprise-cloud?tool=api#uploading-your-migration-archives-to-github-owned-blob-storage)」を参照してください。 1. GitHub Enterprise Server の管理アカウントから、任意のページの右上隅にあるをクリックします。 2. \[ Site admin] サイドバーで、**\[\[Management Console]]** をクリックします。 3. \[Management Console] にサインインします。 4. 左側のサイドバーで、**\[Migrations]** をクリックします。 5. **\[Enable GitHub Migrations]** をクリックします。 6. \[Migrations Storage] で **\[Local Storage]** をクリックします。 7. **[Save settings](設定の保存)** をクリックします。移行を実行するときは、GitHub Enterprise Server のディスク領域を監視します。移行アーカイブは 7 日後に自動的に削除されます。領域を解放するには、「[組織の移行用の REST API エンドポイント](/ja/enterprise-server@3.18/rest/migrations/orgs#delete-an-organization-migration-archive)」を使用してアーカイブを削除します。 ### BLOB ストレージプロバイダーを使用する GitHub Enterprise Server インスタンスがファイアウォールの内側にある場合は、外部クラウドサービスを使用して BLOB ストレージを設定することが必要になる場合があります。まず、サポートされているプロバイダーを使って BLOB ストレージを設定する必要があります。次に、クラウドプロバイダーを使用している場合は、 \[Management Console] または GitHub CLIでストレージプロバイダーの資格情報を構成する必要があります。 GitHub CLI は、次の BLOB ストレージプロバイダーをサポートしています。 * アマゾンウェブサービス (AWS) S3 * Azure Blob Storage > \[!NOTE] > BLOB ストレージを構成する必要があるのは、 GitHub Enterprise Server バージョン 3.8 以降を使用している場合のみです。バージョン 3.7 以前GitHub Enterprise Server使用する場合は、「[手順 4: GitHub Enterprise Cloudで移行ソースを設定](#step-4-set-up-a-migration-source-in-github-enterprise-cloud)する」に進んでください。 > > 大規模な Git ソースまたはメタデータを含むリポジトリを移行するには、BLOB ストレージが必要です。バージョン 3.7 以下 GitHub Enterprise Server 使用している場合、Git ソースまたはメタデータのエクスポートが 2 GB を超える移行を実行することはできません。これらの移行を実行するには、 GitHub Enterprise Server バージョン 3.8 以降に更新します。 #### AWS S3 ストレージバケットの設定 AWS で、S3 バケットを設定します。詳しくは、AWS のドキュメント「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)」をご覧ください。次のアクセス許可を持つ AWS アクセスキーと秘密鍵も必要です。 ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListBucket", "s3:DeleteObject", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::github-migration-bucket", "arn:aws:s3:::github-migration-bucket/*" ] } ] } ``` > \[!NOTE] > GitHub Enterprise Importer は、移行の完了後に AWS からアーカイブを削除しません。ストレージコストを減らすため、一定期間後にアーカイブが自動削除されるよう構成することをお勧めします。詳しくは、AWS のドキュメントの「[バケットのライフサイクル設定の指定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html)」をご覧ください。 #### Azure Blob Storage アカウントの設定 Azure でストレージアカウントを作成し、接続文字列を記録しておきます。詳しくは、Microsoft Docs の「[ストレージアカウントアクセスキーを管理する](https://learn.microsoft.com/en-gb/azure/storage/common/storage-account-keys-manage?tabs=azure-portal#regenerate-access-keys)」をご覧ください。 > \[!NOTE] > GitHub Enterprise Importer は、移行の完了後に Azure Blob Storage からアーカイブを削除しません。ストレージコストを減らすため、一定期間後にアーカイブが自動削除されるよう構成することをお勧めします。詳しくは、Microsoft Docs の「[データライフサイクルを自動管理してコストを最適化する](https://learn.microsoft.com/en-us/azure/storage/blobs/lifecycle-management-overview)」をご覧ください。 #### \[Management Console] のお使いの GitHub Enterprise Server インスタンスでの Blob ストレージの構成 AWS S3 ストレージバケットまたはAzure Blob Storageアカウントを設定したら、\[Management Console]のお使いの GitHub Enterprise Server インスタンスで BLOB ストレージを構成します。 \[Management Console]の詳細については、「[管理コンソールからのインスタンスの管理](/ja/enterprise-server@3.18/admin/administering-your-instance/administering-your-instance-from-the-web-ui)」を参照してください。 1. GitHub Enterprise Serverの管理アカウントで、任意のページの右上隅にある \[] をクリックします。 2. \[サイト管理者] ページにまだアクセスしていない場合は、左上隅の \[ **サイト管理者**] をクリックします。 1. \[ Site admin] サイドバーで、**\[\[Management Console]]** をクリックします。 3. \[Management Console]にログインします。 4. 上部のナビゲーションバーで **\[設定]** をクリックします。 5. \[**移行**] の \[**GitHub移行を有効にする**] をクリックします。 6. 必要に応じて、 GitHub Actions用に構成したストレージ設定をインポートするには、\[ **アクション] から \[ストレージ設定のコピー**] を選択します。詳細については、「[Azure Blob ストレージで GitHub Actions を有効化する](/ja/enterprise-server@3.18/admin/managing-github-actions-for-your-enterprise/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-azure-blob-storage)」と「[Amazon S3 ストレージで GitHub Actions を有効化する](/ja/enterprise-server@3.18/admin/managing-github-actions-for-your-enterprise/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-amazon-s3-storage)」を参照してください。 > \[!NOTE] > ストレージ設定をコピーした後も、 GitHub Enterprise Importerで動作するようにクラウドストレージアカウントの構成を更新する必要がある場合があります。特に、 GitHubの IP アドレスが許可リストに登録されていることを確認する必要があります。詳しくは、「[GitHub 製品間の移行のためのアクセスの管理](/ja/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#configuring-ip-allow-lists-for-migrations)」をご覧ください。 7. GitHub Actionsからストレージ設定をインポートしない場合は、**Azure Blob Storage**または **Amazon S3** を選択し、必要な詳細を入力します。 > \[!NOTE] > Amazon S3 を使用する場合は、バケットが配置されている AWS リージョンの標準エンドポイントに "AWS サービス URL" を設定する必要があります。たとえば、バケットが`eu-west-1`リージョンにある場合、「AWS サービス URL」は `https://s3.eu-west-1.amazonaws.com` です。 > GitHub Enterprise Server インスタンスのネットワークでは、このホストへのアクセスを許可する必要があります。ゲートウェイエンドポイントはサポートされていません。次に`bucket.vpce-0e25b8cdd720f900e-argc85vg.s3.eu-west-1.vpce.amazonaws.com`のような例を示します。ゲートウェイエンドポイントの詳細については、[AWS ドキュメントの Amazon S3](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html) ゲートウェイエンドポイントを参照してください。 8. **\[ストレージの設定をテストする]** をクリックします。 9. **[Save settings](設定の保存)** をクリックします。 #### ネットワークアクセスの許可ストレージアカウントでファイアウォール規則を構成している場合は、移行先の IP 範囲へのアクセスを許可していることを確認します。「[GitHub 製品間の移行のためのアクセスの管理](/ja/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#configuring-ip-allow-lists-for-migrations)」を参照してください。 ## 手順 4: 移行元をセットアップする GitHub Enterprise Cloud `createMigrationSource` クエリを使って、移行元を設定できます。 `GetOrgInfo` クエリで収集した `ownerId` つまり Organization ID を指定する必要があります。移行ソースは、 GitHub Enterprise Server上の組織です。 ### `createMigrationSource` の変異 ```graphql mutation createMigrationSource($name: String!, $url: String!, $ownerId: ID!) { createMigrationSource(input: {name: $name, url: $url, ownerId: $ownerId, type: GITHUB_ARCHIVE}) { migrationSource { id name url type } } } ``` > \[!NOTE] > `type` には `GITHUB_ARCHIVE` を使用するようにしてください。 | クエリ変数 | 説明 | | --------- | ---------------------------------------------------------- | | `name` | 移行元の名前。この名前は自分の参照用であるため、任意の文字列を使用できます。 | | `ownerId` | GitHub Enterprise Cloud での Organization の Organization ID。 | | `url` | お使いの GitHub Enterprise Server インスタンスの URL。この URL には、 GitHub Enterprise Cloudからアクセスできる必要はありません。 ### `createMigrationSource` に対する応答 ```json { "data": { "createMigrationSource": { "migrationSource": { "id": "MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ", "name": "GHES Source", "url": "https://my-ghes-hostname.com", "type": "GITHUB_ARCHIVE" } } } } ``` この例では、`MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ` が移行元 ID です。これを後の手順で使用します。 ## 手順 5: 移行アーカイブを生成するお使いの GitHub Enterprise Server インスタンス REST API を使用して、 GitHub Enterprise Serverで 2 つの "移行" を開始します。1 つはリポジトリの Git ソースのアーカイブを生成し、もう 1 つはリポジトリのメタデータ (問題やプル要求など) のアーカイブを生成します。 Git ソースアーカイブを生成するには、`POST`への`https://HOSTNAME/api/v3/orgs/ORGANIZATION/migrations`要求を行い、`HOSTNAME`をお使いの GitHub Enterprise Server インスタンスのホスト名に置き換え、`ORGANIZATION`を組織のログインに置き換えます。本文で、移行する 1 つのリポジトリを指定します。要求はこのようになります。 ```http POST /api/v3/orgs/acme-corp/migrations HTTP/1.1 Accept: application/vnd.github+json Authorization: Bearer Content-Type: application/json Host: github.acmecorp.net { "repositories": ["repository_to_migrate"], "exclude_metadata": true } ``` メタデータアーカイブを生成するには、次の本文を使用して同じ URL に同様の要求を送信します。 ```json { "repositories": ["repository_to_migrate"], "exclude_git_data": true, "exclude_releases": false, "exclude_owner_projects": true } ``` これら 2 つの API 呼び出しのそれぞれで、開始した移行の ID を含む JSON 応答が返されます。 ```http HTTP/1.1 201 Created { "id": 123, // ... } ``` 詳細については、「[Organization の移行を開始する](/ja/enterprise-server@3.18/rest/migrations/orgs#start-an-organization-migration)」を参照してください。データの量によっては、アーカイブの生成に時間がかかる場合があります。 "Organization の移行状態を取得する" API を使用して、移行の `state` が `exported` に変わるまで、2 つの移行の状態を定期的に確認できます。 ```http GET /api/v3/orgs/acme-corp/migrations/123 HTTP/1.1 Accept: application/vnd.github+json Authorization: Bearer Host: github.acmecorp.net HTTP/1.1 200 OK Content-Type: application/json { "id": 123, "state": "exported", // ... } ``` 詳細については、「[Organization の移行状態を取得する](/ja/enterprise-server@3.18/rest/migrations/orgs#get-an-organization-migration-status)」を参照してください。 > \[!NOTE] > 移行が `failed` 状態ではなく `exported` 状態になった場合は、もう一度移行を開始してみてください。移行が繰り返し失敗する場合は、API の代わりに `ghe-migrator` を使用してアーカイブを生成することをお勧めします。 > > [Enterprise からの移行データのエクスポート](/ja/enterprise-server@3.18/migrations/using-ghe-migrator/exporting-migration-data-from-github-enterprise-server)に関する記事の手順に従って、移行にリポジトリを 1 つだけ追加します。このプロセスを終えると、Git ソースとメタデータを含む 1 つの移行アーカイブができ、この記事の手順 6 に進むことができます。移行の `state` が `exported` に移動したら、「組織移行アーカイブのダウンロード」API を使用して移行の URL を取得できます。 ```http GET /api/v3/orgs/acme-corp/migrations/123/archive HTTP/1.1 Accept: application/vnd.github+json Authorization: Bearer Host: github.acmecorp.net HTTP/1.1 302 Found Location: https://media.github.acmecorp.net/migrations/123/archive/cca2ebe9-7403-4ffa-9b6a-4c9e16c94410?token=AAAAABEWE7JP4H2HACKEGMTDOYRC6 ``` この API を使用すると、ダウンロード可能なアーカイブが配置された URL にリダイレクトする `302 Found` ヘッダーを含む `Location` 応答が返されます。 2 つのファイルをダウンロードします。1 つは Git ソース、もう 1 つはメタデータのファイルです。詳細については、「[Organization の移行アーカイブをダウンロードする](/ja/enterprise-server@3.18/rest/migrations/orgs#download-an-organization-migration-archive)」を参照してください。両方の移行が完了し、アーカイブをダウンロードしたら、次の手順に進むことができます。 ## 手順 6: 移行アーカイブをアップロードするデータを GitHub Enterprise Cloudにインポートするには、GraphQL API を使用して、各リポジトリ (Git ソースとメタデータ) の両方のアーカイブをコンピューターから GitHubに渡す必要があります。 GitHub Enterprise Server 3.7 以下を使用している場合は、まず、GitHubがアクセスできるアーカイブの URL を生成する必要があります。ほとんどのお客様は、Amazon S3 や Azure Blob Storage などのクラウドプロバイダーの BLOB ストレージサービスにアーカイブをアップロードし、それぞれについて有効期間の短い URL を生成することを選びます。 GitHub Enterprise Server 3.8 以降を使用している場合、インスタンスによってアーカイブがアップロードされ、URL が生成されます。前の手順の `Location` ヘッダーにより、有効期間の短い URL が返されます。 GitHub の IP 範囲を許可リストに追加する必要がある場合があります。詳しくは、「[GitHub 製品間の移行のためのアクセスの管理](/ja/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#configuring-ip-allow-lists-for-migrations)」をご覧ください。 ### GitHub-owned blob storage への移行アーカイブのアップロード GitHub-owned blob storageを使用している場合は、次のプロセスを使用してアーカイブをGitHub-owned blob storageにアップロードします。 1. POST 要求を送信してマルチパートアップロードを作成する 2. PATCH 要求として、最大 100 MB のサイズのアーカイブを複数のパーツに分けてアップロードする 3. PUT 要求を送信してアップロードを完了する #### 1.マルチパートアップロードを作成する次の宛先に POST 要求を送信します。 ```http https://uploads.github.com/organizations/{organization_id}/gei/archive/blobs/uploads ``` アーカイブ名とサイズを指定した次のような JSON 本文を含めます。どのアップロードでも、コンテンツタイプを `"application/octet-stream"` のままにすることができます。 ```json { "content_type": "application/octet-stream", "name": "git-archive.tar.gz", "size": 262144000 } ``` 次のような JSON オブジェクト応答が返されます。 ```json { "guid": "363b2659-b8a3-4878-bfff-eed4bcb54d35", "node_id": "MA_kgDaACQzNjNiMjY1OS1iOGEzLTQ4NzgtYmZmZi1lZWQ0YmNiNTRkMzU", "name": "git-archive.tar.gz", "size": 33287, "uri": "gei://archive/363b2659-b8a3-4878-bfff-eed4bcb54d35", "created_at": "2024-11-13T12:35:45.761-08:00" } ``` この URI はアップロードされたアーカイブを表します。また、リポジトリの移行を開始するときに移行をエンキューするために使われます。応答には応答ヘッダーの location も含まれます。これは、次のステップで PATCH 要求を使ってファイルのパーツをアップロードする際に利用します。 ```http /organizations/{organization_id}/gei/archive/blobs/uploads?part_number=1&guid=&upload_id= ``` #### 2.アーカイブを複数のパーツに分けてアップロードする先ほどの応答ヘッダーの location を使って PATCH 要求を送信し、ファイルを 1 パーツにつき最大 100MB にしてアップロードします。その際、マルチパートフォームは使わず、生データを要求本文に含めてアップロードします。ファイルの最後のパーツが 100 MB 未満の場合は、最後の要求で残ったバイト分のみをアップロードします。 ```http https://uploads.github.com/{location} ``` この結果、空の応答本文が返され、応答ヘッダーには次の場所が設定されます。 ```http /organizations/{organization_id}/gei/archive/blobs/uploads?part_number=2&guid=&upload_id= ``` アップロードが完了するまでこれを繰り返します。一度に最大 100 MB のファイルを読み取り、`part_number` 値を増分した新しい location 値に要求を送信するようにします。 #### 3.アップロードを完了する前のステップの "最後のパス" 値に空の本文を含む PUT 要求を送信すると、GitHub 所有のストレージへのアップロードが完了します。 GEI URI は、この最初の POST 要求に含まれる GUID を使って、次の形式で構築できます。 ```http gei://archive/{guid} ``` ## 手順 7: リポジトリの移行を開始する移行を始める、1 つのリポジトリとそれに付随するデータが、ユーザーが指定した新しい GitHub リポジトリに移行されます。同じ移行元 Organization から複数のリポジトリを一度に移動したい場合は、複数の移行をキューに登録できます。同時に最大 5 つのリポジトリの移行を実行できます。 ### `startRepositoryMigration` の変異 ```graphql mutation startRepositoryMigration ( $sourceId: ID!, $ownerId: ID!, $repositoryName: String!, $continueOnError: Boolean!, $accessToken: String!, $githubPat: String!, $gitArchiveUrl: String!, $metadataArchiveUrl: String!, $sourceRepositoryUrl: URI!, $targetRepoVisibility: String! ){ startRepositoryMigration( input: { sourceId: $sourceId, ownerId: $ownerId, repositoryName: $repositoryName, continueOnError: $continueOnError, accessToken: $accessToken, githubPat: $githubPat, targetRepoVisibility: $targetRepoVisibility gitArchiveUrl: $gitArchiveUrl, metadataArchiveUrl: $metadataArchiveUrl, sourceRepositoryUrl: $sourceRepositoryUrl, }) { repositoryMigration { id migrationSource { id name type } sourceUrl } } } ``` | クエリ変数 | 説明 | | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `sourceId` | `createMigrationSource` ミューテーションから返された移行元の `id`。 | | `ownerId` | GitHub Enterprise Cloud での Organization の Organization ID。 | | `repositoryName` | GitHub Enterprise Cloud 上で Organization が所有するどのリポジトリでも現在使われていない一意のカスタムリポジトリ名。移行が完了または停止すると、このリポジトリにエラーログ issue が作成されます。 | | `continueOnError` | 移行の失敗を引き起こさないエラーが発生したときに移行を続行できるようにする移行設定。 `true` または `false` である必要があります。 Importer が Git ソースを移動できない場合、または Importer が接続を失い、移行を完了するために再接続できない場合を除き、移行が続けられるように、`continueOnError` を `true` に設定することを強くお勧めします。 | | `githubPat` | personal access token 上の移行先 Organization の GitHub Enterprise Cloud。 | | `accessToken` | 移行元の personal access token。 | | `targetRepoVisibility` | 新しいリポジトリの可視性。 `private`、`public`、または `internal` にする必要があります。設定されていない場合、リポジトリはプライベートとして移行されます。 | `gitArchiveUrl` |Git ソースアーカイブの GitHub Enterprise Cloudアクセス可能な URL。 `metadataArchiveUrl` |メタデータアーカイブの GitHub Enterprise Cloudアクセス可能な URL。 `sourceRepositoryUrl` | GitHub Enterprise Server インスタンス上のリポジトリの URL。これは必須ですが、 GitHub Enterprise Cloud は GitHub Enterprise Server インスタンスと直接通信しません。 personal access token要件については、[GitHub 製品間の移行のためのアクセスの管理](/ja/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#required-scopes-for-personal-access-tokens) を参照してください。次のステップでは、`startRepositoryMigration` ミューテーションから返された移行 ID を使って、移行の状態を調べます。 ## 手順 8: 移行の状態を確認する移行エラーを検出し、移行が行われていることを確認するには、`getMigration` クエリを使って移行の状態を調査できます。また、`getMigrations` を使うと、複数の移行の状態を調べることもできます。 `getMigration` クエリから返される状態を調べて、移行が `queued`、`in progress`、`failed`、または `completed` であるかどうかを確認できます。移行が失敗した場合、Importer によってエラーの原因が示されます。 #### `getMigration` クエリ ```graphql query ( $id: ID! ){ node( id: $id ) { ... on Migration { id sourceUrl migrationSource { name } state failureReason } } } ``` | クエリ変数 | 説明 | | ----- | -------------------------------------------------------------------------------------- | | `id` | [`startRepositoryMigration` ミューテーション](#startrepositorymigration-mutation)が返した移行の `id`。 | ## 手順 9: 移行を検証し、エラーログを確認する移行を完了するには、"移行ログ" の issue を確認することをお勧めします。この issue は、移行先リポジトリの GitHub に作成されます。 !["移行ログ" というタイトルの issue のスクリーンショット。 issue の 2 番目のコメントに、移行に関するログが含まれます。](/assets/images/help/github-enterprise-importer/migration-log-issue.png) 最後に、移行したリポジトリで健全性チェックを確認することをお勧めします。

## 手順 1: GEI extension of the GitHub CLIをインストールしてください。これが初めての移行の場合は、GEI extension of the GitHub CLI をインストールする必要があります。 GitHub CLI の詳細については、「[GitHub CLI について](/ja/enterprise-server@3.18/github-cli/github-cli/about-github-cli)」を参照してください。または、`github/gh-gei` リポジトリの「[リリースページ](https://github.com/github/gh-gei/releases)」からスタンドアロンバイナリをダウンロードすることもできます。 `gh` プレフィックスなしでバイナリを直接実行できます。 1. GitHub CLI をインストールします。 GitHub CLI のインストール手順については、[GitHub CLI リポジトリ](https://github.com/cli/cli#installation)を参照してください。 > \[!NOTE] > GitHub CLI のバージョン 2.4.0 以降が必要です。 `gh --version` コマンドを使って、インストールされているバージョンを確認できます。 2. GEI extension をインストールします。 ```shell copy gh extension install github/gh-gei ``` GEI extension に関するヘルプが必要なときはいつでも、コマンドで `--help` フラグを使用できます。たとえば、`gh gei --help` とすると使用可能なすべてのコマンドの一覧が表示され、`gh gei migrate-repo --help` とすると `migrate-repo` コマンドで使用できるすべてのオプションの一覧が表示されます。 ## 手順 2: GEI extension of the GitHub CLI を更新します GEI extension は毎週更新されます。最新バージョンを確実に使うため、拡張機能を更新してください。 ```shell gh extension upgrade github/gh-gei ``` ## 手順 3: 環境変数を設定する GEI extension を使って GitHub Enterprise Cloud に移行するには、その前に、移行元と移行先の Organization にアクセスできる personal access token を作成してから、personal access token を環境変数として設定する必要があります。 1. personal access token (classic) 上の移行先 Organization に対して認証を行う GitHub Enterprise Cloud を作成して記録し、トークンがすべての要件を満たしていることを確認します。詳しくは、「[GitHub 製品間の移行のためのアクセスの管理](/ja/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#creating-a-personal-access-token-for-github-enterprise-importer)」をご覧ください。 2. 移行元 Organization に対して認証を行う personal access token を作成して記録し、このトークンも同じ要件をすべて満たしていることを確認します。 3. personal access token に対する環境変数を設定します。次のコマンドの TOKEN は、上で記録した personal access token に置き換えます。移行先の Organization には `GH_PAT` を使い、移行元の Organization には `GH_SOURCE_PAT` を使います。 * ターミナルを使っている場合は、`export` コマンドを使います。 ```shell copy export GH_PAT="TOKEN" export GH_SOURCE_PAT="TOKEN" ``` * PowerShell を使っている場合は、`$env` コマンドを使います。 ```shell copy $env:GH_PAT="TOKEN" $env:GH_SOURCE_PAT="TOKEN" ``` 4. データ所在地付き GitHub Enterprise Cloudに移行する場合は、便宜上、エンタープライズの**ベース API URL** の環境変数を設定します。 `SUBDOMAIN`を企業のサブドメインに置き換えてください。たとえば、企業のサブドメインが `acme`されている場合、 `TARGET_API_URL` の値は `https://api.acme.ghe.com`されます。 * ターミナルを使っている場合は、`export` コマンドを使います。 ```shell copy export TARGET_API_URL="https://api.SUBDOMAIN.ghe.com" ``` * PowerShell を使っている場合は、`$env` コマンドを使います。 ```shell copy $env:TARGET_API_URL="https://api.SUBDOMAIN.ghe.com" ``` この変数は、`--target-api-url`で実行するコマンドの GitHub CLI オプションと共に使用します。 ## 手順 4: BLOB ストレージを設定する ### GitHub-owned blob storage を使用したリポジトリの移行リポジトリアーカイブを格納するための顧客所有の BLOB ストレージアカウントへのアクセスを GitHub Enterprise Importer に設定して提供したくない場合は、 GitHub-owned blob storageを使用してリポジトリを移行できます。これを行うには、v1.9.0 (またはそれ以降) の GEI extension of the GitHub CLIを実行している必要があります。 GitHub-owned blob storage は追加のセットアップを必要とせず、 GEI extension of the GitHub CLI コマンドを実行するときにオプションとして使用できます。セキュリティ上の理由から、 GitHub-owned blob storage は明示的に書き込み専用であり、 GitHub-owned blob storage からダウンロードすることはできません。移行が完了すると、リポジトリアーカイブは直ちに削除されます。アーカイブがアップロードされ、移行で使われなかった場合、アーカイブは 7 日後に削除されます。 GitHub-owned blob storageに CLI フラグを使用すると、管理コンソールで構成された宛先にリポジトリアーカイブが自動的にエクスポートされ、GitHub所有ストレージにアップロードされ、移行先にインポートされます。 GitHub-owned blob storageを使用する場合は、ローカルストレージを構成することをお勧めします。「[ローカルストレージの使用 (GHES 3.16 以降)](#using-local-storage-ghes-316-1)」を参照してください。 ### お客様所有の BLOB ストレージを使ったリポジトリの移行 GitHub がアクセスできる場所にリポジトリデータを格納する必要があります。 GitHub Enterprise Server インスタンスがファイアウォールの内側にある場合は、外部クラウドサービスを使って BLOB ストレージを設定することが必要な場合があります。まず、サポートされているプロバイダーを使って BLOB ストレージを設定する必要があります。次に、クラウドプロバイダーをお使いの場合は、\[Management Console] または GitHub CLI でストレージプロバイダーの資格情報を構成する必要があります。 GitHub CLI は、次の BLOB ストレージプロバイダーをサポートしています。 * アマゾンウェブサービス (AWS) S3 * Azure Blob Storage * GHES インスタンス上のローカルストレージ (GHES **3.16** 以降)。 GitHub-owned blob storage ではこのオプションを使うことをお勧めします。 ### AWS S3 ストレージバケットの設定 AWS で、S3 バケットを設定します。詳しくは、AWS のドキュメント「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)」をご覧ください。次のアクセス許可を持つ AWS アクセスキーと秘密鍵も必要です。 ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListBucket", "s3:DeleteObject", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::github-migration-bucket", "arn:aws:s3:::github-migration-bucket/*" ] } ] } ``` > \[!NOTE] > GitHub Enterprise Importer は、移行の完了後に AWS からアーカイブを削除しません。ストレージコストを減らすため、一定期間後にアーカイブが自動削除されるよう構成することをお勧めします。詳しくは、AWS のドキュメントの「[バケットのライフサイクル設定の指定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html)」をご覧ください。 ### Azure Blob Storage アカウントの設定 Azure でストレージアカウントを作成し、接続文字列を記録しておきます。詳しくは、Microsoft Docs の「[ストレージアカウントアクセスキーを管理する](https://learn.microsoft.com/en-gb/azure/storage/common/storage-account-keys-manage?tabs=azure-portal#regenerate-access-keys)」をご覧ください。 > \[!NOTE] > GitHub Enterprise Importer は、移行の完了後に Azure Blob Storage からアーカイブを削除しません。ストレージコストを減らすため、一定期間後にアーカイブが自動削除されるよう構成することをお勧めします。詳しくは、Microsoft Docs の「[データライフサイクルを自動管理してコストを最適化する](https://learn.microsoft.com/en-us/azure/storage/blobs/lifecycle-management-overview)」をご覧ください。 ### ローカルストレージ (GHES 3.16 以降) の使用ローカルストレージを使用して移行を実行すると、クラウドストレージプロバイダーを必要とせずに、お使いの GitHub Enterprise Server インスタンス上のディスクにアーカイブデータが書き込まれます。 * GitHub Enterprise Server からのエグレストラフィックをブロックするファイアウォール規則がない場合、GitHub Enterprise Importer は、GitHub Enterprise Server から格納されたアーカイブを自動的に取得できます。 * ファイアウォール規則が設定されていて、GitHub Enterprise Importer へのアクセスを許可したくない場合は、アーカイブデータを GitHub-owned blob storage にアップロードして、GitHub Enterprise Importer がアクセスできるようにすることができます。手動で行うには、この記事の API バージョンの「[移行アーカイブを GitHub 所有の BLOB ストレージにアップロードする](/ja/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/migrating-repositories-from-github-enterprise-server-to-github-enterprise-cloud?tool=api#uploading-your-migration-archives-to-github-owned-blob-storage)」を参照してください。 1. GitHub Enterprise Server の管理アカウントから、任意のページの右上隅にあるをクリックします。 2. \[ Site admin] サイドバーで、**\[\[Management Console]]** をクリックします。 3. \[Management Console] にサインインします。 4. 左側のサイドバーで、**\[Migrations]** をクリックします。 5. **\[Enable GitHub Migrations]** をクリックします。 6. \[Migrations Storage] で **\[Local Storage]** をクリックします。 7. **[Save settings](設定の保存)** をクリックします。移行を実行するときは、GitHub Enterprise Server のディスク領域を監視します。移行アーカイブは 7 日後に自動的に削除されます。領域を解放するには、「[組織の移行用の REST API エンドポイント](/ja/enterprise-server@3.18/rest/migrations/orgs#delete-an-organization-migration-archive)」を使用してアーカイブを削除します。 ### ブロブストレージの資格情報を構成する (ローカルストレージではなく) **クラウドプロバイダー** で BLOB ストレージを設定する場合は、 GitHubでストレージプロバイダーの資格情報を構成する必要があります。 * GitHub Enterprise Server 3.8 以降を使用する場合は、\[Management Console]で資格情報を構成します。 * GitHub Enterprise Server 3.7 以下を使用する場合は、GitHub CLIで資格情報を構成します。 #### \[Management Console] のお使いの GitHub Enterprise Server インスタンスでの Blob ストレージの構成 > \[!NOTE] > \[Management Console] 3.8 以降を使用する場合にのみ、GitHub Enterprise Serverで BLOB ストレージを構成する必要があります。 3.7 以下を使用する場合は、代わりに GitHub CLI で資格情報を構成します。 AWS S3 ストレージバケットまたはAzure Blob Storageアカウントを設定したら、\[Management Console]のお使いの GitHub Enterprise Server インスタンスで BLOB ストレージを構成します。 \[Management Console]の詳細については、「[管理コンソールからのインスタンスの管理](/ja/enterprise-server@3.18/admin/administering-your-instance/administering-your-instance-from-the-web-ui)」を参照してください。 1. GitHub Enterprise Serverの管理アカウントで、任意のページの右上隅にある \[] をクリックします。 2. \[サイト管理者] ページにまだアクセスしていない場合は、左上隅の \[ **サイト管理者**] をクリックします。 1. \[ Site admin] サイドバーで、**\[\[Management Console]]** をクリックします。 3. \[Management Console]にログインします。 4. 上部のナビゲーションバーで **\[設定]** をクリックします。 5. \[**移行**] の \[**GitHub移行を有効にする**] をクリックします。 6. 必要に応じて、 GitHub Actions用に構成したストレージ設定をインポートするには、\[ **アクション] から \[ストレージ設定のコピー**] を選択します。詳細については、「[Azure Blob ストレージで GitHub Actions を有効化する](/ja/enterprise-server@3.18/admin/managing-github-actions-for-your-enterprise/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-azure-blob-storage)」と「[Amazon S3 ストレージで GitHub Actions を有効化する](/ja/enterprise-server@3.18/admin/managing-github-actions-for-your-enterprise/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-amazon-s3-storage)」を参照してください。 > \[!NOTE] > ストレージ設定をコピーした後も、 GitHub Enterprise Importerで動作するようにクラウドストレージアカウントの構成を更新する必要がある場合があります。特に、 GitHubの IP アドレスが許可リストに登録されていることを確認する必要があります。詳しくは、「[GitHub 製品間の移行のためのアクセスの管理](/ja/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#configuring-ip-allow-lists-for-migrations)」をご覧ください。 7. GitHub Actionsからストレージ設定をインポートしない場合は、**Azure Blob Storage**または **Amazon S3** を選択し、必要な詳細を入力します。 > \[!NOTE] > Amazon S3 を使用する場合は、バケットが配置されている AWS リージョンの標準エンドポイントに "AWS サービス URL" を設定する必要があります。たとえば、バケットが`eu-west-1`リージョンにある場合、「AWS サービス URL」は `https://s3.eu-west-1.amazonaws.com` です。 > GitHub Enterprise Server インスタンスのネットワークでは、このホストへのアクセスを許可する必要があります。ゲートウェイエンドポイントはサポートされていません。次に`bucket.vpce-0e25b8cdd720f900e-argc85vg.s3.eu-west-1.vpce.amazonaws.com`のような例を示します。ゲートウェイエンドポイントの詳細については、[AWS ドキュメントの Amazon S3](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html) ゲートウェイエンドポイントを参照してください。 8. **\[ストレージの設定をテストする]** をクリックします。 9. **[Save settings](設定の保存)** をクリックします。 ### GitHub CLI での Blob ストレージの資格情報の構成 > \[!NOTE] > GitHub CLIで BLOB ストレージ資格情報を構成する必要があるのは、GitHub Enterprise Server 3.7 以下を使用する場合のみです。 3.8 以降を使用する場合は、代わりに \[Management Console] で BLOB ストレージを構成します。 > > GitHub CLIで BLOB ストレージの資格情報を構成した場合、Git ソースまたはメタデータのエクスポートが 2 GB を超える移行を実行することはできません。これらの移行を実行するには、 GitHub Enterprise Server 3.8 以降にアップグレードします。 #### で AWS S3 認証情報を設定する GitHub CLI 移行を実行する準備ができたら、リージョン、アクセスキー、シークレットキー、セッショントークンなどの AWS 資格情報を GitHub CLI に提供します (必要な場合)。引数として渡すことも、`AWS_REGION`、`AWS_ACCESS_KEY_ID`、`AWS_SECRET_ACCESS_KEY`、`AWS_SESSION_TOKEN` という環境変数を設定することもできます。また、`--aws-bucket-name` 引数を使って S3 バケットの名前で渡す必要があります。 #### GitHub CLIでの Azure Blob Storage アカウントの資格情報の構成移行を実行する準備ができたら、接続文字列を引数として GitHub CLI に渡すか、`AZURE_STORAGE_CONNECTION_STRING` という名前の環境変数を使って渡すことができます。 ### ネットワークアクセスの許可ストレージアカウントでファイアウォール規則を構成している場合は、移行先の IP 範囲へのアクセスを許可していることを確認します。「[GitHub 製品間の移行のためのアクセスの管理](/ja/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#configuring-ip-allow-lists-for-migrations)」を参照してください。 ## 手順 5: 移行スクリプトを生成する複数のリポジトリを GitHub Enterprise Cloud に一度に移行したい場合は、GitHub CLI を使って移行スクリプトを生成します。結果のスクリプトには、リポジトリごとに 1 つの移行コマンドのリストが含まれます。 > \[!NOTE] > スクリプトを生成すると、PowerShell スクリプトが出力されます。ターミナルを使っている場合は、`.ps1` ファイル拡張子を持つスクリプトを出力し、[Mac](https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-macos?view=powershell-7.2) または [Linux](https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-linux?view=powershell-7.2) 用の PowerShell をインストールして実行する必要があります。 1 つのリポジトリを移行する場合は、次のステップに進んでください。 ### 移行スクリプトの生成お使いの GitHub Enterprise Server インスタンス用の API にアクセスできるコンピューターから、このステップを行う必要があります。ブラウザーからインスタンスにアクセスできる場合、そのコンピューターには正しいアクセス権があります。移行スクリプトを生成するには、`gh gei generate-script` コマンドを実行します。 GitHub Enterprise Server 3.8 以降の場合、または Azure Blob Storage で 3.7 以下を使用している場合は、次のフラグを使用します。 ```shell copy gh gei generate-script --github-source-org SOURCE \ --github-target-org DESTINATION \ --output FILENAME \ --ghes-api-url GHES-API-URL ``` AWS S3 で GitHub Enterprise Server 3.7 以下を使用している場合は、次のフラグを使用します。 ```shell copy gh gei generate-script --github-source-org SOURCE \ --github-target-org DESTINATION \ --output FILENAME \ --ghes-api-url GHES-API-URL \ --aws-bucket-name AWS-BUCKET-NAME ``` #### プレースホルダー上のコマンドのプレースホルダーを次の値に置き換えます。 | プレースホルダー | 値 | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | SOURCE | 移行元の Organization の名前 | | DESTINATION | 移行先の Organization の名前 | | FILENAME | 結果の移行スクリプトのファイル名

ターミナルを使っている場合は、生成されたスクリプトの実行に PowerShell が必要なので、`.ps1` ファイル拡張子を使います。 [Mac](https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-macos?view=powershell-7.2) 用または [Linux](https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-linux?view=powershell-7.2) 用の PowerShell をインストールできます。 | | GHES-API-URL | お使いの GitHub Enterprise Server インスタンスの API の URL (例: `https://myghes.com/api/v3`) | | AWS-BUCKET-NAME | AWS S3 バケットのバケット名 | #### 追加の引数 | 引数 | 説明 | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--download-migration-logs` | 移行された各リポジトリの移行ログをダウンロードします。移行ログの詳細については、「[GitHub Enterprise Importer の移行ログへのアクセス](/ja/enterprise-server@3.18/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/accessing-your-migration-logs-for-github-enterprise-importer#downloading-all-the-repository-migration-logs-for-a-migration-script)」を参照してください。 | | `--lock-source-repo` | 移行時にソースリポジトリをロックします。 | | **警告：** ソースリポジトリをロックすると、それ以上の変更が行われなくなり、ワークフローが中断される可能性があります。このオプションは、適切であると確信できる場合にのみ使用することをお勧めします。詳しくは、「[ロックされたリポジトリについて](/ja/enterprise-server@3.18/migrations/overview/about-locked-repositories)」をご覧ください。 | | | `--no-ssl-verify` | お使いの GitHub Enterprise Server インスタンスで自己署名証明書または無効な SSL 証明書が使われている場合は、`--no-ssl-verify` フラグを使います。このフラグを使うと、GitHub CLI は、ユーザーのインスタンスのみからデータを抽出するときは、SSL 証明書の検証をスキップします。その他のすべての呼び出しでは、SSL が検証されます。 | | `--skip-releases` | リポジトリに 10 GB を超えるリリースデータがある場合、リリースを移行することはできません。リリースなしでリポジトリを移行するには、`--skip-releases` フラグを使います。 | | `--target-api-url TARGET-API-URL` | GHE.com に移行する場合は、`--target-api-url TARGET-API-URL` を追加します。TARGET-API-URL は Enterprise のサブドメインのベース API URL です。 (例: `https://api.octocorp.ghe.com`)。 | | `--use-github-storage` | 中間 BLOB ストレージソリューションとして GitHub-owned blob storage を使用して、リポジトリの移行を実行します。 | ### 移行スクリプトの確認スクリプトを生成したら、ファイルを確認し、必要に応じてスクリプトを編集します。 * 移行したくないリポジトリがある場合は、対応する行を削除するかコメントにします。 * 移行先の Organization でリポジトリに別の名前を使う場合は、対応する `--target-repo` フラグの値を更新します。 * 新しいリポジトリの可視性を変更する場合は、対応する `--target-repo-visibility` フラグの値を更新します。既定では、スクリプトはソースリポジトリと同じ表示範囲を設定します。リポジトリに 10 GB を超えるリリースデータがある場合、リリースを移行することはできません。リリースなしでリポジトリを移行するには、`--skip-releases` フラグを使います。 GEI の拡張機能としてではなく、スタンドアロンバイナリとして GitHub CLI をダウンロードした場合は、生成されたスクリプトを更新して `gh gei` ではなくバイナリを実行する必要があります。 ## 手順 6: リポジトリを移行する移行スクリプトを使って複数のリポジトリを移行すること、または `gh gei migrate-repo` コマンドを使って 1 つのリポジトリを移行することができます。リポジトリを移行すると、 GEI extension of the GitHub CLI は次の手順を実行します。 1. お使いの GitHub Enterprise Server インスタンスに接続し、リポジトリごとに 2 つの移行アーカイブを生成します。1 つは Git ソース用、1 つはメタデータ用です 2. 移行アーカイブを任意の BLOB ストレージプロバイダーにアップロードします 3. BLOB ストレージプロバイダーに格納されているアーカイブの URL を使用して、 GitHub Enterprise Cloudで移行を開始します 4. ローカルコンピューターから移行アーカイブを削除します ### 複数のリポジトリを移行する GitHub Enterprise Server 3.7 以前から移行する場合は、スクリプトを実行する前に、BLOB ストレージプロバイダーに対して認証するための追加の環境変数を設定する必要があります。 * Azure Blob Storageは、`AZURE_STORAGE_CONNECTION_STRING` を Azure ストレージアカウントの接続文字列に設定します。ストレージアカウントのアクセスキーを使う接続文字列のみがサポートされています。 Shared Access Signature (SAS) を使う接続文字列はサポートされていません。ストレージアカウントのアクセスキーについて詳しくは、Azure のドキュメントの「[ストレージアカウントアクセスキーを管理する](https://learn.microsoft.com/en-gb/azure/storage/common/storage-account-keys-manage?tabs=azure-portal#regenerate-access-keys)」をご覧ください。 * AWS S3は、次の環境変数を設定します。 * `AWS_ACCESS_KEY_ID`: バケットのアクセスキー ID * `AWS_SECRET_ACCESS_KEY`: バケットの秘密鍵 * `AWS_REGION`: バケットが配置されている AWS リージョン * `AWS_SESSION_TOKEN`: AWS の一時的な資格情報を使用している場合のセッショントークン (AWS ドキュメントの「[AWS リソースで一時的な資格情報を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html)」を参照してください) 複数のリポジトリを移行するには、生成したスクリプトを実行します。次のコマンドの FILENAME を、スクリプトの生成時に指定したファイル名に置き換えます。 * ターミナルを使っている場合は、`./` を使います。 ```shell copy ./FILENAME ``` * PowerShell を使っている場合は、`.\` を使います。 ```shell copy .\FILENAME ``` ### 1 つのリポジトリを移行するお使いの GitHub Enterprise Server インスタンス用の API にアクセスできるコンピューターから、このステップを行う必要があります。ブラウザーからインスタンスにアクセスできる場合、そのコンピューターには正しいアクセス権があります。 1 つのリポジトリを移行するには、`gh gei migrate-repo` コマンドを使います。 GitHub Enterprise Server 3.8 以降を使用している場合は、次のフラグを使用します。 ```shell copy gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME --ghes-api-url GHES-API-URL ``` GitHub Enterprise Server 3.7 以前から移行し、BLOB ストレージプロバイダーとして Azure Blob Storage を使用している場合は、次のフラグを使用して認証します。 ```shell copy gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \ --ghes-api-url GHES-API-URL --azure-storage-connection-string "AZURE_STORAGE_CONNECTION_STRING" ``` GitHub Enterprise Server 3.7 以前から移行し、Blob Storage プロバイダーとして Amazon S3 を使用している場合は、次のフラグを使用して認証します。 ```shell copy gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \ --ghes-api-url GHES-API-URL --aws-bucket-name "AWS-BUCKET-NAME" ``` #### プレースホルダー上のコマンドのプレースホルダーを次の値に置き換えます。 | プレースホルダー | 値 | | ---------------------------------- | --------------------------------------------------------------------------------- | | SOURCE | 移行元の Organization の名前 | | CURRENT-NAME | 移行するリポジトリの名前 | | DESTINATION | 移行先の Organization の名前 | | NEW-NAME | 移行されたリポジトリに設定する名前 | | GHES-API-URL | お使いの GitHub Enterprise Server インスタンスの API の URL (例: `https://myghes.com/api/v3`) | | AZURE\_STORAGE\_CONNECTION\_STRING | Azure ストレージアカウントの接続文字列。

接続文字列は必ず引用符で囲みます。それには、シェルで誤って解釈される可能性がある文字が含まれます。 | | AWS-BUCKET-NAME | AWS S3 バケットのバケット名 | #### 追加の引数 | 引数 | 説明 | | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--lock-source-repo` | 移行時にソースリポジトリをロックします。詳しくは、「[ロックされたリポジトリについて](/ja/enterprise-server@3.18/migrations/overview/about-locked-repositories)」をご覧ください。 | | `--no-ssl-verify` | お使いの GitHub Enterprise Server インスタンスで自己署名証明書または無効な SSL 証明書が使われている場合は、`--no-ssl-verify` フラグを使います。このフラグを使うと、GitHub CLI は、ユーザーのインスタンスのみからデータを抽出するときは、SSL 証明書の検証をスキップします。その他のすべての呼び出しでは、SSL が検証されます。 | | `--skip-releases` | リポジトリに 10 GB を超えるリリースデータがある場合、リリースを移行することはできません。リリースなしでリポジトリを移行するには、`--skip-releases` フラグを使います。 | | `--target-api-url TARGET-API-URL` | GHE.com に移行する場合は、`--target-api-url TARGET-API-URL` を追加します。TARGET-API-URL は Enterprise のサブドメインのベース API URL です。 (例: `https://api.octocorp.ghe.com`)。 | | `--target-repo-visibility TARGET-VISIBILITY` | リポジトリは、既定では表示範囲が非公開で移行されます。表示範囲を設定するには、`--target-repo-visibility` フラグを追加し、`private`、`public`、または `internal` を指定します。マネージドユーザーを含む Enterprise に移行する場合、パブリックリポジトリは使用できません。 | | `--use-github-storage` | 中間 BLOB ストレージソリューションとして GitHub-owned blob storage を使用して、リポジトリの移行を実行します。 | #### 移行プロセスの中断移行を取り消す場合は、MIGRATION-ID を `abort-migration` 返された（ `migrate-repo`から）ID に置き換えて、コマンドを使用します。 ```shell copy gh gei abort-migration --migration-id MIGRATION-ID ``` ## 手順 7: 移行を検証し、エラーログを確認する移行が完了したら、移行ログを確認することをお勧めします。詳しくは、「[GitHub Enterprise Importer の移行ログへのアクセス](/ja/enterprise-server@3.18/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/accessing-your-migration-logs-for-github-enterprise-importer)」をご覧ください。ソースリポジトリにルールセットが含まれていて、それらのルールセットによってブロックされている場合は、 [リポジトリ移行のルールセットのバイパス設定](/ja/enterprise-cloud@latest/migrations/troubleshooting/setting-ruleset-bypasses-for-repository-migrations) を参照してください。移行したリポジトリで健全性チェックを確認することをお勧めします。移行が完了したら、ストレージコンテナーからアーカイブを削除することをお勧めします。追加の移行を完了する予定の場合は、 ADO2GH extensionによってストレージコンテナーに配置されたアーカイブを削除します。移行が完了したら、コンテナー全体を削除できます。