将存储库从 GitHub Enterprise Server 迁移到 GitHub Enterprise Cloud

如果选择使用 API，则需要编写自己的脚本或使用 HTTP 客户端（如 Insomnia）。 可以在“REST API 入门”和“使用 GraphQL 建立调用”中详细了解如何开始使用 GitHub 的 API。

若要使用 API 将存储库从 GitHub Enterprise Server 迁移到 GitHub Enterprise Cloud，将执行以下操作：

1. 为源组织和目标组织创建 personal access token
2. 获取目标组织在 GitHub Enterprise Cloud 上的 ownerId
3. 通过 GitHub 的 GraphQL API 设置迁移源，确定要从何处迁移
4. 对于要迁移的每个存储库重复以下步骤。
   • 使用 你的 GitHub Enterprise Server 实例 上的 REST API 为存储库生成迁移存档
   • 将迁移存档上传到 GitHub 可以访问的位置
   • 使用迁移目标的 GraphQL API 开始迁移，并传入存档 URL
   • 通过 GraphQL API 检查迁移状态
   • 验证迁移并检查错误日志

若要查看使用 GitHub CLI 的说明，请使用页面顶部的工具切换器。

步骤 1。 创建 personal access token

1. 创建并记录一个 personal access token (classic)，用于在 GitHub Enterprise Cloud 上为目标组织进行身份验证，确保令牌满足所有要求。 有关详细信息，请参阅“管理 GitHub 产品之间迁移的访问权限”。
2. 创建并记录一个 personal access token，用于对源组织进行身份验证的，确保此令牌也满足所有相同的要求。

步骤 2：获取目标组织的 ownerId

作为 GitHub Enterprise Cloud 中的组织所有者，请使用 GetOrgInfo 查询为要拥有已迁移存储库的组织返回 ownerId（也称为组织 ID）。 需要使用 ownerId 来标识迁移目标。

GetOrgInfo 查询

query(
  $login: String!
){
  organization (login: $login)
  {
    login
    id
    name
    databaseId
  }
}

GetOrgInfo 响应

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

在此示例中，MDEyOk9yZ2FuaXphdGlvbjU2MTA= 是组织 ID 或 ownerId，在下一步中会用到它。

步骤 3：设置 blob 存储

由于许多 GitHub Enterprise Server 实例都位于防火墙后面，因此对于 GitHub Enterprise Server 3.8 或更高版本，我们使用 blob 存储作为中间位置来存储 GitHub 可以访问的数据。

必须先使用受支持的云提供商设置 blob 存储，然后在 你的 GitHub Enterprise Server 实例 的 管理控制台 中配置设置。

使用受支持的云提供商设置 blob 存储

GitHub CLI 支持以下 Blob 存储提供程序：

• Amazon Web Services (AWS) S3
• Azure Blob 存储

设置 AWS S3 存储桶

在 AWS 中，设置 S3 Bucket。 有关详细信息，请参阅 AWS 文档中的创建 Bucket。

还需要具有以下权限的 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/*"
            ]
        }
    ]
}

设置 Azure Blob 存储帐户

在 Azure 中，创建存储帐户并记下连接字符串。 有关详细信息，请参阅 Microsoft Docs 中的管理存储帐户访问密钥。

在 你的 GitHub Enterprise Server 实例 的 管理控制台 中配置 blob 存储

设置 AWS S3 存储桶或 Azure Blob 存储存储帐户后，请在 你的 GitHub Enterprise Server 实例 的 管理控制台 中配置 Blob 存储。 有关 管理控制台 的详细信息，请参阅“从管理控制台管理实例”。

1. 在 GitHub Enterprise Server 上的管理帐户中，在任一页面的右上角，单击“”。

2. 如果你还没有进入“站点管理员”页面，请单击左上角的“站点管理员”。1. 在“ 站点管理”边栏中，单击“管理控制台”。

3. 登录到 管理控制台。

4. 在顶部导航栏中，单击“设置”。

5. 在“迁移”下，单击“启用 GitHub 迁移” 。

6. （可选）要导入为 GitHub Actions 配置的存储设置，请选择“从 Actions 复制存储设置”。 有关详细信息，请参阅“使用 Azure Blob 存储启用 GitHub Actions”和“使用 Amazon S3 存储启用 GitHub Actions”。

   Note

   复制存储设置后，仍可能需要更新云存储帐户的配置才能与 GitHub Enterprise Importer 一起使用。 尤其是务必要将 GitHub 的 IP 地址加入允许列表。 有关详细信息，请参阅“管理 GitHub 产品之间迁移的访问权限”。

7. 如果不从 GitHub Actions 导入存储设置，请选择“Azure Blob 存储”或“Amazon S3”并填写所需的详细信息 。

   Note

   如果使用 Amazon S3，必须将“AWS 服务 URL”设置为存储桶所在 AWS 区域的标准端点。 例如，如果存储桶位于 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. 单击“保存设置”。

允许网络访问

如果在存储帐户上配置了防火墙规则，请确保已允许访问迁移目标的 IP 范围。 请参阅“管理 GitHub 产品之间迁移的访问权限”。

步骤 4：在 GitHub Enterprise Cloud 中设置迁移源

可以使用 createMigrationSource 查询设置迁移源。 需要提供从 GetOrgInfo 查询收集的 ownerId 或组织 ID。

迁移源是你在 GitHub Enterprise Server 上的组织。

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

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 中启动两个“迁移”：一个用于生成存储库 Git 源的存档，另一个用于生成存储库元数据（例如议题和拉取请求）的存档。

若要生成 Git 源存档，请向 https://HOSTNAME/api/v3/orgs/ORGANIZATION/migrations 发出 POST 请求，将 HOSTNAME 替换为 你的 GitHub Enterprise Server 实例 的主机名，并将 ORGANIZATION 替换为组织的登录名。

在正文中，指定要迁移的单个存储库。 请求应类似于：

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
}

这两个 API 调用中的每一个都将返回一个 JSON 响应，其中包括已开始的迁移的 ID。

HTTP/1.1 201 Created

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

有关详细信息，请参阅开始组织迁移。

生成存档可能需要一段时间，具体取决于数据量。 可以通过“获取组织迁移状态”API 定期查看两个迁移的状态，直到迁移的 state 变为 exported。

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",
  // ...
}

有关详细信息，请参阅获取组织迁移状态。

迁移的 state 变为 exported 后，可以使用“下载组织迁移存档”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 将返回带有 Location 标头的 302 Found 响应，该标头重定向到可下载存档所在的 URL。 下载这两个文件：一个用于 Git 源，一个用于元数据。

有关详细信息，请参阅下载组织迁移存档。

完成两个迁移并下载存档后，可以转到下一步骤。

步骤 6：上传迁移存档

若要将数据导入 GitHub Enterprise Cloud，必须使用我们的 GraphQL API 将每个存储库（Git 源和元数据）的存档从你的计算机传递到 GitHub。

如果使用 GitHub Enterprise Server 3.7 或更低版本，则必须先为 GitHub 可访问的存档生成 URL。 大多数客户选择将存档上传到云提供商的 blob 存储服务（例如 Amazon S3 或 Azure Blob 存储），然后为每个存档生成一个短期 URL。

如果使用 GitHub Enterprise Server 3.8 或更高版本，则实例将上传存档并生成 URL。 上一步中的 Location 标头将返回短期 URL。

你可能需要将 GitHub 的 IP 范围列入允许列表。 有关详细信息，请参阅“管理 GitHub 产品之间迁移的访问权限”。

步骤 7：开始存储库迁移

开始迁移时，单个存储库及其随附的数据将迁移到你标识的全新 GitHub 存储库。

如果要从同一源组织一次移动多个存储库，则可以将多个迁移排入队列。 最多可以同时运行 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
    }
  }
}

有关 personal access token 要求的信息，请参阅“管理 GitHub 产品之间迁移的访问权限”。

在下一步中，将使用从 startRepositoryMigration 突变返回的迁移 ID 来检查迁移状态。

步骤 8：检查迁移状态

要检测任何迁移失败并确保迁移正常工作，可以使用 getMigration 查询检查迁移状态。 还可以使用 getMigrations 检查多个迁移的状态。

getMigration 查询将返回状态，让你知道迁移状态是 queued、in progress、failed 还是 completed。 如果迁移失败，Importer 将提供失败原因。

getMigration 查询

query (
  $id: ID!
){
  node( id: $id ) {
    ... on Migration {
      id
      sourceUrl
      migrationSource {
        name
      }
      state
      failureReason
    }
  }
}

步骤 9：验证迁移并检查错误日志

要完成迁移，建议检查“迁移日志”问题。 此问题在目标存储库中的 GitHub 上创建。

最后，建议查看已迁移的存储库以进行完整性检查。