Skip to main content

GitHub Enterprise Server から GitHub Enterprise Cloud へのリポジトリの移行

GitHub CLI または API を使用して GitHub Enterprise Server から GitHub Enterprise Cloud にリポジトリを移行できます。

Tool navigation

GitHub Enterprise Importer

を使ったリポジトリの移行について

GitHub CLI または API を使って、移行を実行できます。

GitHub CLI を使うと移行プロセスが簡単になるので、ほとんどのお客様に推奨されます。 カスタマイズのニーズが高い熟練したお客様は、API を使って、GitHub Enterprise Importer との独自の統合を構築できます。

API を使用することを選んだ場合は、独自のスクリプトを記述するか、Insomnia などの HTTP クライアントを使用する必要があります。 GitHub の API の概要については、「REST API を使用した作業の開始」と「GraphQLでの呼び出しの作成」を参照してください。

API を使用してリポジトリを GitHub Enterprise Server から GitHub Enterprise Cloud に移行するには、次のようにします。

  1. 移行元と移行先の両方の Organization に対して personal access token を作成します
  2. GitHub Enterprise Cloud で移行先 Organization の ownerId をフェッチします
  3. GitHub.com の GraphQL API を使用して移行元を設定し、どこから移行するかを特定します
  4. 移行するリポジトリごとに、次の手順を繰り返します。
    • お使いの GitHub Enterprise Server インスタンス で、REST API を使用してリポジトリの移行アーカイブを生成します
    • GitHub.com からアクセスできる場所に移行アーカイブをアップロードします
    • GitHub.com の GraphQL API を使用して移行を開始し、アーカイブの URL を渡します
    • GraphQL API を使用して移行の状態を確認します
    • 移行を検証し、エラー ログを確認します

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

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

前提条件

  • 移行の試験的実行を行い、そのすぐ後で運用環境の移行を完了することを強くお勧めします。 試験的実行について詳しくは、「GitHub 製品間の移行に関する概要」をご覧ください。
  • 移行されるデータと、Importer の既知のサポート制限事項を理解していることを確認します。 詳しくは、「GitHub 製品間の移行について」をご覧ください。
  • 必須ではありませんが、運用環境の移行の間は作業を停止することをお勧めします。 Importer は差分移行をサポートしていないため、移行中に発生した変更は移行されません。 運用環境の移行の間に作業を停止しない場合は、これらの変更を手動で移行する必要があります。
  • ユーザーは、移行元 Organization と移行先 Organization の両方で Organization の所有者である、または移行者ロールが付与されている必要があります。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。
  • GitHub Enterprise Server 3.8 以降を使用する場合は、[Management Console] にアクセスできる必要があります。

手順 1. personal access token を作成する

  1. GitHub Enterprise Cloud 上の移行先 Organization に対して認証を行う personal access token (classic) を作成して記録し、トークンがすべての要件を満たしていることを確認します。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。
  2. 移行元 Organization に対して認証を行う personal access token を作成して記録し、このトークンも同じ要件をすべて満たしていることを確認します。

手順 2: 移行先 Organization の ownerId を取得する

GitHub Enterprise Cloud の Organization 所有者として、GetOrgInfo クエリを使って、移行されたリポジトリを所有する Organization の ownerId (Organization ID とも呼ばれます) を取得します。 移行先を識別するには、ownerId が必要です。

GetOrgInfo クエリ

query(
  $login: String!
){
  organization (login: $login)
  {
    login
    id
    name
    databaseId
  }
}
クエリ変数説明
loginOrganization の名前。

GetOrgInfo の応答

{
  "data": {
    "organization": {
      "login": "Octo",
      "id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
      "name": "Octo-org",
      "databaseId": 5610
    }
  }
}

この例では、MDEyOk9yZ2FuaXphdGlvbjU2MTA= が Organization ID つまり ownerId であり、次のステップでそれを使います。

手順 3: BLOB ストレージを設定する

多くの GitHub Enterprise Server インスタンスはファイアウォールの内側にあるため、GitHub Enterprise Server バージョン 3.8 以降では、GitHub がアクセスできるデータを格納するための中間的な場所として、BLOB ストレージを使用します。

最初に、サポートされているクラウド プロバイダーで BLOB ストレージを設定してから、お使いの GitHub Enterprise Server インスタンス の [Management Console] で設定を構成する必要があります。

: BLOB ストレージを構成する必要があるのは、GitHub Enterprise Server バージョン 3.8 以降を使用している場合のみです。 GitHub Enterprise Server バージョン 3.7 以前を使用している場合は、「手順 4: GitHub Enterprise Cloud で移行元を設定する」に進んでください。

大規模な Git ソースまたはメタデータを含むリポジトリを移行するには、BLOB ストレージが必要です。 GitHub Enterprise Server バージョン 3.7 以前を使用している場合、Git ソースまたはメタデータのエクスポートが 2 GB を超える移行を実行することはできません。 これらの移行を実行するには、GitHub Enterprise Server バージョン 3.8 以降に更新してください。

サポートされているクラウド プロバイダーを使用して BLOB ストレージを設定する

GitHub CLI は、次の BLOB ストレージ プロバイダーをサポートしています。

  • アマゾン ウェブ サービス (AWS) S3
  • Azure Blob Storage

AWS S3 ストレージ バケットの設定

AWS で、S3 バケットを設定します。 詳しくは、AWS のドキュメント「バケットの作成」をご覧ください。

次のアクセス許可を持つ AWS アクセス キーと秘密鍵も必要です。

{
    "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/*"
            ]
        }
    ]
}

注: GitHub Enterprise Importer は、移行の完了後に AWS からアーカイブを削除しません。 ストレージ コストを減らすため、一定期間後にアーカイブが自動削除されるよう構成することをお勧めします。 詳しくは、AWS のドキュメントの「バケットのライフサイクル設定の指定」をご覧ください。

Azure Blob Storage アカウントの設定

Azure でストレージ アカウントを作成し、接続文字列を記録しておきます。 詳しくは、Microsoft Docs の「ストレージ アカウント アクセス キーを管理する」をご覧ください。

注: GitHub Enterprise Importer は、移行の完了後に Azure Blob Storage からアーカイブを削除しません。 ストレージ コストを減らすため、一定期間後にアーカイブが自動削除されるよう構成することをお勧めします。 詳しくは、Microsoft Docs の「データ ライフサイクルを自動管理してコストを最適化する」をご覧ください。

お使いの GitHub Enterprise Server インスタンス の [Management Console] での BLOB ストレージの構成

AWS S3 ストレージ バケットまたは Azure Blob Storage ストレージ アカウントを設定したら、お使いの GitHub Enterprise Server インスタンス の [Management Console] で BLOB ストレージを構成します。 [Management Console] について詳しくは、「管理コンソールからのインスタンスの管理」をご覧ください。

  1. GitHub Enterprise Server の管理アカウントから、任意のページの右上隅にある をクリックします。

  2. [サイト管理者] ページが表示されていない場合は、左上隅の [サイト管理者] をクリックします。1. [ サイト管理者] サイドバーで [Management Console] をクリックします。

  3. [Management Console] にログインします。

  4. 上部のナビゲーション バーで [設定] をクリックします。

  5. [移行] で、 [GitHub の移行を有効にする] をクリックします。

  6. GitHub Actions に構成したストレージの設定をインポートする必要がある場合は、 [Actions からストレージの設定をコピーする] をオンにします。 詳しくは、「Azure Blob ストレージで GitHub Actions を有効化する」と「Amazon S3 ストレージで GitHub Actions を有効化する」をご覧ください。

    : ストレージ設定をコピーした後も、GitHub Enterprise Importer で動作するようにクラウド ストレージ アカウントの構成を更新する必要がある場合があります。 特に、GitHub の IP アドレスを許可リストに載せる必要があります。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。

  7. GitHub Actions からストレージの設定をインポートしない場合は、 [Azure Blob Storage] または [Amazon S3] を選び、必要な詳細を入力します。

    : 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 ゲートウェイエンドポイントを参照してください。

  8. [ストレージの設定をテストする] をクリックします。

  9. Save settings をクリックします。

手順 4: GitHub Enterprise Cloud で移行元を設定する

createMigrationSource クエリを使って、移行元を設定できます。 GetOrgInfo クエリで収集した ownerId つまり Organization ID を指定する必要があります。

移行元は、GitHub Enterprise Server 上の Organization です。

createMigrationSource のミューテーション

mutation createMigrationSource($name: String!, $url: String!, $ownerId: ID!) {
  createMigrationSource(input: {name: $name, url: $url, ownerId: $ownerId, type: GITHUB_ARCHIVE}) {
    migrationSource {
      id
      name
      url
      type
    }
  }
}

注: type には必ず GITHUB_ARCHIVE を使ってください。

クエリ変数説明
name移行元の名前。 この名前は自分の参照用であるため、任意の文字列を使用できます。
ownerIdGitHub Enterprise Cloud での Organization の Organization ID。
urlお使いの GitHub Enterprise Server インスタンス の URL。 この URL は、GitHub Enterprise Cloud からアクセスできる必要はありません。

createMigrationSource の応答

{
  "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 つはリポジトリのメタデータ (issue や pull request など) のアーカイブを生成します。

Git ソース アーカイブを生成するには、https://HOSTNAME/api/v3/orgs/ORGANIZATION/migrations に対して POST 要求を行います。HOSTNAME は お使いの GitHub Enterprise Server インスタンス のホスト名に、ORGANIZATION は Organization のログインに置き換えます。

本文で、移行する 1 つのリポジトリを指定します。 要求はこのようになります。

POST /api/v3/orgs/acme-corp/migrations HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Content-Type: application/json
Host: github.acmecorp.net

{
  "repositories": ["repository_to_migrate"],
  "exclude_metadata": true
}

メタデータ アーカイブを生成するには、次の本文を使用して同じ URL に同様の要求を送信します。

{
  "repositories": ["repository_to_migrate"],
  "exclude_git_data": true,
  "exclude_releases": false,
  "exclude_owner_projects": true
}

これら 2 つの API 呼び出しのそれぞれで、開始した移行の ID を含む JSON 応答が返されます。

HTTP/1.1 201 Created

{
  "id": 123,
  // ...
}

詳細については、「Organization の移行を開始する」を参照してください。

データの量によっては、アーカイブの生成に時間がかかる場合があります。 "Organization の移行状態を取得する" API を使用して、移行の stateexported に変わるまで、2 つの移行の状態を定期的に確認できます。

GET /api/v3/orgs/acme-corp/migrations/123 HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Host: github.acmecorp.net

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "state": "exported",
  // ...
}

詳細については、「Organization の移行状態を取得する」を参照してください。

注: 移行が exported 状態ではなく failed 状態になった場合は、もう一度移行を開始してみてください。 移行が繰り返し失敗する場合は、API の代わりに ghe-migrator を使用してアーカイブを生成することをお勧めします。

Enterprise から移行データをエクスポートする」の手順に従い、移行にリポジトリを 1 つだけ追加します。 このプロセスを終えると、Git ソースとメタデータを含む 1 つの移行アーカイブができ、この記事の手順 6 に進むことができます。

移行の stateexported に推移したら、"Organization 移行アーカイブのダウンロード" API を使用して移行の URL をフェッチできます。

GET /api/v3/orgs/acme-corp/migrations/123/archive HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
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 にリダイレクトする Location ヘッダーを含む 302 Found 応答が返されます。 2 つのファイルをダウンロードします。1 つは Git ソース、もう 1 つはメタデータのファイルです。

詳細については、「Organization の移行アーカイブをダウンロードする」を参照してください。

両方の移行が完了し、アーカイブをダウンロードしたら、次の手順に進むことができます。

手順 6: 移行アーカイブをアップロードする

GitHub Enterprise Cloud にデータをインポートするには、GraphQL API を使用して、自分のマシンから GitHub.com に各リポジトリの両方のアーカイブ (Git ソースとメタデータ) を渡す必要があります。

GitHub Enterprise Server 3.7 以前を使用している場合は、GitHub.com からアクセスできるアーカイブの URL を最初に生成する必要があります。 ほとんどのお客様は、Amazon S3 や Azure Blob Storage などのクラウド プロバイダーの BLOB ストレージ サービスにアーカイブをアップロードし、それぞれについて有効期間の短い URL を生成することを選びます。

GitHub Enterprise Server 3.8 以降を使用している場合は、インスタンスからアーカイブがアップロードされ、URL が生成されます。 前の手順の Location ヘッダーにより、有効期間の短い URL が返されます。

GitHub の IP 範囲を許可リストに加えることが必要になる場合があります。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。

手順 7: リポジトリの移行を開始する

移行を始める、1 つのリポジトリとそれに付随するデータが、ユーザーが指定した新しい GitHub リポジトリに移行されます。

同じ移行元 Organization から複数のリポジトリを一度に移動したい場合は、複数の移行をキューに登録できます。 同時に最大 5 つのリポジトリの移行を実行できます。

startRepositoryMigration のミューテーション

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
    }
  }
}
クエリ変数説明
sourceIdcreateMigrationSource ミューテーションから返された移行元の id
ownerIdGitHub Enterprise Cloud での Organization の Organization ID。
repositoryNameGitHub Enterprise Cloud 上で Organization が所有するどのリポジトリでも現在使われていない一意のカスタム リポジトリ名。 移行が完了または停止すると、このリポジトリにエラー ログ issue が作成されます。
continueOnError移行の失敗を引き起こさないエラーが発生したときに移行を続行できるようにする移行設定。 true または false である必要があります。 Importer が Git ソースを移動できない場合、または Importer が接続を失い、移行を完了するために再接続できない場合を除き、移行が続けられるように、continueOnErrortrue に設定することを強くお勧めします。
githubPatGitHub Enterprise Cloud 上の移行先 Organization の personal access token。
accessToken移行元の personal access token。
targetRepoVisibility新しいリポジトリの可視性。 privatepublic、または internal にする必要があります。 設定されていない場合、リポジトリはプライベートとして移行されます。
gitArchiveUrlGitHub Enterprise Cloud でアクセス可能な Git ソース アーカイブの URL。
metadataArchiveUrlGitHub Enterprise Cloud でアクセス可能なメタデータ アーカイブの URL。
sourceRepositoryUrlGitHub Enterprise Server インスタンス上のリポジトリの URL。 これは必須ですが、GitHub Enterprise Cloud と GitHub Enterprise Server インスタンスは直接通信しません。

personal access token の要件については、「GitHub 製品間の移行のためのアクセスの管理」をご覧ください。

次のステップでは、startRepositoryMigration ミューテーションから返された移行 ID を使って、移行の状態を調べます。

手順 8: 移行の状態を確認する

移行エラーを検出し、移行が行われていることを確認するには、getMigration クエリを使って移行の状態を調査できます。 また、getMigrations を使うと、複数の移行の状態を調べることもできます。

getMigration クエリから返される状態を調べて、移行が queuedin progressfailed、または completed であるかどうかを確認できます。 移行が失敗した場合、Importer によってエラーの原因が示されます。

getMigration クエリ

query (
  $id: ID!
){
  node( id: $id ) {
    ... on Migration {
      id
      sourceUrl
      migrationSource {
        name
      }
      state
      failureReason
    }
  }
}
クエリ変数説明
idstartRepositoryMigration ミューテーションが返した移行の id

手順 9: 移行を検証し、エラー ログを確認する

移行を完了するには、"移行ログ" の issue を確認することをお勧めします。 この issue は、移行先リポジトリの GitHub に作成されます。

"移行ログ" というタイトルの issue のスクリーンショット。 issue の 2 番目のコメントに、移行に関するログが含まれます。

最後に、移行したリポジトリで健全性チェックを確認することをお勧めします。

手順 1: GEI extension of the GitHub CLI をインストールする

これが初めての移行の場合は、GEI extension of the GitHub CLI をインストールする必要があります。 GitHub CLI について詳しくは、「GitHub CLI について」をご覧ください。

または、github/gh-gei リポジトリの「リリース ページ」からスタンドアロン バイナリをダウンロードすることもできます。 gh プレフィックスなしでバイナリを直接実行できます。

  1. GitHub CLI をインストールします。 GitHub CLI のインストール手順については、GitHub CLI リポジトリを参照してください。

    注: GitHub CLI のバージョン 2.4.0 以降が必要です。 gh --version コマンドを使って、インストールされているバージョンを確認できます。

  2. GEI extension をインストールします。

    Shell
    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 は毎週更新されます。 最新バージョンを確実に使うため、拡張機能を更新してください。

gh extension upgrade github/gh-gei

手順 3: 環境変数を設定する

GEI extension を使って GitHub Enterprise Cloud に移行するには、その前に、移行元と移行先の Organization にアクセスできる personal access token を作成してから、personal access token を環境変数として設定する必要があります。

  1. GitHub Enterprise Cloud 上の移行先 Organization に対して認証を行う personal access token (classic) を作成して記録し、トークンがすべての要件を満たしていることを確認します。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。

  2. 移行元 Organization に対して認証を行う personal access token を作成して記録し、このトークンも同じ要件をすべて満たしていることを確認します。

  3. personal access token に対する環境変数を設定します。次のコマンドの TOKEN は、上で記録した personal access token に置き換えます。 移行先の Organization には GH_PAT を使い、移行元の Organization には GH_SOURCE_PAT を使います。

    • ターミナルを使っている場合は、export コマンドを使います。

      Shell
      export GH_PAT="TOKEN"
      export GH_SOURCE_PAT="TOKEN"
      
    • PowerShell を使っている場合は、$env コマンドを使います。

      Shell
      $env:GH_PAT="TOKEN"
      $env:GH_SOURCE_PAT="TOKEN"
      

手順 4: BLOB ストレージを設定する

多くの GitHub Enterprise Server インスタンスはファイアウォールの内側にあるため、GitHub がアクセスできるデータを格納するための中間的なの場所として、BLOB ストレージを使用します。

まず、サポートされているクラウド プロバイダーを使用して BLOB ストレージを設定する必要があります。 次に、[Management Console] または GitHub CLI でストレージ プロバイダーの資格情報を構成する必要があります。

サポートされているクラウド プロバイダーを使用した BLOB ストレージの設定

GitHub CLI は、次の BLOB ストレージ プロバイダーをサポートしています。

  • アマゾン ウェブ サービス (AWS) S3
  • Azure Blob Storage

AWS S3 ストレージ バケットの設定

AWS で、S3 バケットを設定します。 詳しくは、AWS のドキュメント「バケットの作成」をご覧ください。

次のアクセス許可を持つ AWS アクセス キーと秘密鍵も必要です。

{
    "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/*"
            ]
        }
    ]
}

注: GitHub Enterprise Importer は、移行の完了後に AWS からアーカイブを削除しません。 ストレージ コストを減らすため、一定期間後にアーカイブが自動削除されるよう構成することをお勧めします。 詳しくは、AWS のドキュメントの「バケットのライフサイクル設定の指定」をご覧ください。

Azure Blob Storage ストレージ アカウントの設定

Azure でストレージ アカウントを作成し、接続文字列を記録しておきます。 詳しくは、Microsoft Docs の「ストレージ アカウント アクセス キーを管理する」をご覧ください。

注: GitHub Enterprise Importer は、移行の完了後に Azure Blob Storage からアーカイブを削除しません。 ストレージ コストを減らすため、一定期間後にアーカイブが自動削除されるよう構成することをお勧めします。 詳しくは、Microsoft Docs の「データ ライフサイクルを自動管理してコストを最適化する」をご覧ください。

BLOB ストレージ資格情報の構成

サポートされているクラウド プロバイダーを使用して BLOB ストレージを設定した後、GitHub でストレージ プロバイダーの資格情報を構成する必要があります。

  • GitHub Enterprise Server 3.8 以降を使用している場合は、[Management Console] で資格情報を構成します。
  • GitHub Enterprise Server 3.7 以前を使用している場合は、GitHub CLI で資格情報を構成します。

お使いの GitHub Enterprise Server インスタンス の [Management Console] での BLOB ストレージの構成

注: GitHub Enterprise Server 3.8 以降を使用している場合にのみ、[Management Console] で BLOB ストレージを構成する必要があります。 3.7 以前を使用している場合は、代わりに GitHub CLI で資格情報を構成します。

AWS S3 ストレージ バケットまたは Azure Blob Storage ストレージ アカウントを設定したら、お使いの GitHub Enterprise Server インスタンス の [Management Console] で BLOB ストレージを構成します。 [Management Console] について詳しくは、「管理コンソールからのインスタンスの管理」をご覧ください。

  1. GitHub Enterprise Server の管理アカウントから、任意のページの右上隅にある をクリックします。

  2. [サイト管理者] ページが表示されていない場合は、左上隅の [サイト管理者] をクリックします。1. [ サイト管理者] サイドバーで [Management Console] をクリックします。

  3. [Management Console] にログインします。

  4. 上部のナビゲーション バーで [設定] をクリックします。

  5. [移行] で、 [GitHub の移行を有効にする] をクリックします。

  6. GitHub Actions に構成したストレージの設定をインポートする必要がある場合は、 [Actions からストレージの設定をコピーする] をオンにします。 詳しくは、「Azure Blob ストレージで GitHub Actions を有効化する」と「Amazon S3 ストレージで GitHub Actions を有効化する」をご覧ください。

    : ストレージ設定をコピーした後も、GitHub Enterprise Importer で動作するようにクラウド ストレージ アカウントの構成を更新する必要がある場合があります。 特に、GitHub の IP アドレスを許可リストに載せる必要があります。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。

  7. GitHub Actions からストレージの設定をインポートしない場合は、 [Azure Blob Storage] または [Amazon S3] を選び、必要な詳細を入力します。

    : 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 ゲートウェイエンドポイントを参照してください。

  8. [ストレージの設定をテストする] をクリックします。

  9. Save settings をクリックします。

GitHub CLI での BLOB ストレージ資格情報の構成

注: GitHub Enterprise Server 3.7 以前を使用している場合にのみ、GitHub CLI で BLOB ストレージの資格情報を構成する必要があります。 3.8 以降を使用している場合は、代わりに [Management Console] で BLOB ストレージを構成します。

GitHub CLI で BLOB ストレージの資格情報を構成した場合、Git ソースまたはメタデータのエクスポートが 2 GB を超える移行を実行することはできません。 これらの移行を実行するには、GitHub Enterprise Server 3.8 以降にアップグレードしてください。

GitHub CLI での AWS S3 資格情報の構成

移行を実行する準備ができたら、リージョン、アクセス キー、シークレット キー、セッション トークンなどの AWS 資格情報を GitHub CLI に提供します (必要な場合)。 引数として渡すことも、AWS_REGIONAWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEYAWS_SESSION_TOKEN という環境変数を設定することもできます。

また、--aws-bucket-name 引数を使って S3 バケットの名前で渡す必要があります。

GitHub CLI での Azure Blob Storage アカウント資格情報の構成

移行を実行する準備ができたら、接続文字列を引数として GitHub CLI に渡すか、AZURE_STORAGE_CONNECTION_STRING という名前の環境変数を使って渡すことができます。

手順 5: 移行スクリプトを生成する

複数のリポジトリを GitHub Enterprise Cloud に一度に移行したい場合は、GitHub CLI を使って移行スクリプトを生成します。 結果のスクリプトには、リポジトリごとに 1 つの移行コマンドのリストが含まれます。

注: スクリプトを生成すると、PowerShell スクリプトが出力されます。 ターミナルを使っている場合は、.ps1 ファイル拡張子を持つスクリプトを出力し、Mac または Linux 用の PowerShell をインストールして実行する必要があります。

1 つのリポジトリを移行する場合は、次のステップに進んでください。

移行スクリプトの生成

お使いの GitHub Enterprise Server インスタンス 用の API にアクセスできるコンピューターから、このステップを行う必要があります。 ブラウザーからインスタンスにアクセスできる場合、そのコンピューターには正しいアクセス権があります。

移行スクリプトを生成するには、gh gei generate-script コマンドを実行します。

GitHub Enterprise Server 3.8 以降の場合、または Azure Blob Storage で 3.7 以前を使っている場合は、次のフラグを使ってください。

Shell
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
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

お使いの GitHub Enterprise Server インスタンス で自己署名証明書または無効な SSL 証明書が使われている場合は、--no-ssl-verify フラグを使います。 このフラグを使うと、GitHub CLI は、ユーザーのインスタンスのみからデータを抽出するときは、SSL 証明書の検証をスキップします。 その他のすべての呼び出しでは、SSL が検証されます。

移行された各リポジトリの移行ログをダウンロードするスクリプトが必要な場合は、--download-migration-logs フラグを追加します。 移行ログについて詳しくは、「GitHub Enterprise Importer の移行ログへのアクセス」をご覧ください。

上のコマンドのプレースホルダーを次の値に置き換えます。

プレースホルダー
SOURCE移行元の Organization の名前
DESTINATION移行先の Organization の名前
FILENAME結果の移行スクリプトのファイル名

ターミナルを使っている場合は、生成されたスクリプトの実行に PowerShell が必要なので、.ps1 ファイル拡張子を使います。 Mac 用または Linux 用の PowerShell をインストールできます。
GHES-API-URLお使いの GitHub Enterprise Server インスタンス の API の URL (例: https://myghes.com/api/v3)
AWS-BUCKET-NAMEAWS S3 バケットのバケット名

移行スクリプトの確認

スクリプトを生成したら、ファイルを確認し、必要に応じてスクリプトを編集します。

  • 移行したくないリポジトリがある場合は、対応する行を削除するかコメントにします。
  • 移行先の Organization でリポジトリに別の名前を使う場合は、対応する --target-repo フラグの値を更新します。

注: リポジトリに 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 のドキュメントの「ストレージ アカウント アクセス キーを管理する」をご覧ください。

  • AWS S3 の場合は、次の環境変数を設定します。

    • AWS_ACCESS_KEY: バケットのアクセス キー
    • AWS_SECRET_KEY: バケットの秘密鍵
    • AWS_REGION: バケットが配置されている AWS リージョン
    • AWS_SESSION_TOKEN: AWS の一時的な資格情報を使っている場合のセッション トークン (AWS ドキュメントの「AWS リソースで一時的な資格情報を使用する」をご覧ください)

複数のリポジトリを移行するには、上で生成したスクリプトを実行します。 次のコマンドの FILENAME を、スクリプトの生成時に指定したファイル名に置き換えます。

  • ターミナルを使っている場合は、./ を使います。

    Shell
    ./FILENAME
    
  • PowerShell を使っている場合は、.\ を使います。

    Shell
    .\FILENAME
    

1 つのリポジトリを移行する

お使いの GitHub Enterprise Server インスタンス 用の API にアクセスできるコンピューターから、このステップを行う必要があります。 ブラウザーからインスタンスにアクセスできる場合、そのコンピューターには正しいアクセス権があります。

1 つのリポジトリを移行するには、gh gei migrate-repo コマンドを使います。

GitHub Enterprise Server 3.8 以降を使っている場合は、次のフラグを使ってください。

Shell
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
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 ストレージ プロバイダーとして Amazon S3 を使っている場合は、次のフラグを使って認証してください。

Shell
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"

お使いの GitHub Enterprise Server インスタンス で自己署名証明書または無効な SSL 証明書が使われている場合は、--no-ssl-verify フラグを使います。 このフラグを使うと、GitHub CLI は、ユーザーのインスタンスのみからデータを抽出するときは、SSL 証明書の検証をスキップします。 その他のすべての呼び出しでは、SSL が検証されます。

注: リポジトリに 10 GB を超えるリリース データがある場合、リリースを移行することはできません。 リリースなしでリポジトリを移行するには、--skip-releases フラグを使います。

上のコマンドのプレースホルダーを次の値に置き換えます。

プレースホルダー
SOURCE移行元の Organization の名前
CURRENT-NAME移行するリポジトリの名前
DESTINATION移行先の Organization の名前
NEW-NAME移行されたリポジトリに設定する名前
GHES-API-URLお使いの GitHub Enterprise Server インスタンス の API の URL (例: https://myghes.com/api/v3)
AZURE_STORAGE_CONNECTION_STRINGAzure ストレージ アカウントの接続文字列。

接続文字列は必ず引用符で囲みます。それには、シェルで誤って解釈される可能性がある文字が含まれます。
AWS-BUCKET-NAMEAWS S3 バケットのバケット名

移行を取り消す場合は、MIGRATION-ID を abort-migration 返された( migrate-repoから)ID に置き換えて、コマンドを使用します。

Shell
gh gei abort-migration --migration-id MIGRATION-ID

手順 7: 移行を検証し、エラー ログを確認する

移行が完了したら、移行ログを確認することをお勧めします。 詳しくは、「GitHub Enterprise Importer の移行ログへのアクセス」を参照してください。

移行したリポジトリで健全性チェックを確認することをお勧めします。

移行が完了したら、ストレージ コンテナーからアーカイブを削除することをお勧めします。 追加の移行を実行する予定の場合は、ADO2GH extension によってストレージ コンテナーに配置されたアーカイブを削除します。 移行が完了したら、コンテナー全体を削除できます。