跳至主要内容

将代码库从 GitHub Enterprise Server 迁移到 GitHub Enterprise Cloud

您可以使用 GitHub CLI 或 API 将代码库从 GitHub Enterprise Server 迁移到 GitHub Enterprise Cloud。

工具导航

关于使用 GitHub Enterprise Importer 进行代码库迁移

您可以使用 GitHub CLI 或 API 运行迁移。

GitHub CLI 简化了迁移过程,建议大多数客户使用。具有大量自定义需求的高级客户可以使用 API 来构建他们自己与 GitHub Enterprise Importer 的集成。

如果您选择使用 API,则需要编写自己的脚本或使用像 Insomnia 这样的 HTTP 客户端。您可以在“REST API 入门”和“使用 GraphQL 形成调用”中了解更多关于 GitHub API 入门的信息。

要使用 API 将您的代码库从 GitHub Enterprise Server 迁移到 GitHub Enterprise Cloud,您需要

  1. 为源组织和目标组织创建个人访问令牌
  2. 获取 GitHub Enterprise Cloud 上目标组织的 `ownerId`
  3. 通过 GitHub 的 GraphQL API 设置迁移源以标识您要从中迁移的位置
  4. 对于要迁移的每个代码库,重复以下步骤。
    • 使用您 GitHub Enterprise Server 实例上的 REST API 为您的代码库生成迁移存档
    • 将您的迁移存档上传到 GitHub 可以访问的位置
    • 使用目标迁移的 GraphQL API 启动迁移,传入您的存档 URL
    • 通过 GraphQL API 检查迁移状态
    • 验证迁移并检查错误日志

要查看使用 API 的说明,请使用页面顶部的工具切换器。

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

先决条件

  • 我们强烈建议您进行迁移试运行,并在之后尽快完成生产迁移。要了解有关试运行的更多信息,请参阅“GitHub 产品之间迁移概述”。
  • 确保您了解将要迁移的数据以及 Importer 的已知支持限制。有关更多信息,请参阅“关于 GitHub 产品之间的迁移”。
  • 虽然不是必需的,但我们建议在生产迁移期间停止工作。Importer 不支持增量迁移,因此迁移期间发生的任何更改都不会迁移。如果您选择不在生产迁移期间停止工作,则需要手动迁移这些更改。
  • 在源组织和目标组织中,您必须是组织所有者或被授予迁移者角色。更多信息,请参阅“GitHub 产品之间迁移的访问管理”。
  • 如果您使用的是 GitHub Enterprise Server 3.8 或更高版本,则需要访问管理控制台才能为导出的存档配置 Blob 存储。

步骤 1. 创建您的个人访问令牌

  1. 创建并记录一个个人访问令牌(经典),用于在 GitHub Enterprise Cloud 上对目标组织进行身份验证,确保该令牌满足所有要求。更多信息,请参阅“GitHub 产品之间迁移的访问管理”。
  2. 创建并记录一个个人访问令牌,用于对源组织进行身份验证,确保此令牌也满足所有相同的要求。

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

作为 GitHub Enterprise Cloud 中的组织所有者,使用GetOrgInfo 查询返回您希望拥有已迁移存储库的组织的ownerId(也称为组织 ID)。您需要ownerId来标识您的迁移目标。

GetOrgInfo 查询

query(
  $login: String!
){
  organization (login: $login)
  {
    login
    id
    name
    databaseId
  }
}
查询变量描述
login您的组织名称。

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 实例的管理控制台中配置您的设置。

注意:只有在使用 GitHub Enterprise Server 3.8 或更高版本时,才需要配置 Blob 存储。如果您使用的是 GitHub Enterprise Server 3.7 或更低版本,请跳到“步骤 4:在 GitHub Enterprise Cloud 中设置迁移源”。

对于具有大型 Git 源代码或元数据的存储库迁移,需要 Blob 存储。如果您使用的是 GitHub Enterprise Server 3.7 或更低版本,则无法执行 Git 源代码或元数据导出超过 2GB 的迁移。要执行这些迁移,请更新到 GitHub Enterprise Server 3.8 或更高版本。

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

GitHub CLI 支持以下 Blob 存储提供商

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

设置 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 存储帐户

在 Azure 中,创建一个存储帐户并记下您的连接字符串。更多信息,请参阅 Microsoft Docs 中的管理存储帐户访问密钥

注意

迁移完成后,GitHub Enterprise Importer 不会从 Azure Blob 存储中删除您的存档。为了降低存储成本,我们建议您在一段时间后配置存档的自动删除。更多信息,请参阅 Microsoft Docs 中的通过自动管理数据生命周期来优化成本

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

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

  1. 在 GitHub Enterprise Server 上的管理帐户中,单击任何页面右上角的.

  2. 如果您尚未进入“站点管理员”页面,请单击左上角的**站点管理员**。

  3. 在“站点管理员”侧边栏中,单击**管理控制台**。

  4. 登录管理控制台。

  5. 在顶部导航栏中,单击**设置**。

  6. 在**迁移**下,单击**启用 GitHub 迁移**。

  7. 可选地,要导入为 GitHub Actions 配置的存储设置,请选择**从 Actions 复制存储设置**。更多信息,请参阅“使用 Azure Blob 存储启用 GitHub Actions”和“使用 Amazon S3 存储启用 GitHub Actions”。

    注意

    复制存储设置后,您可能仍需要更新云存储帐户的配置才能与 GitHub Enterprise Importer 配合使用。特别是,您必须确保 GitHub 的 IP 地址已列入允许列表。更多信息,请参阅“GitHub 产品之间迁移的访问管理”。

  8. 如果您不从 GitHub Actions 导入存储设置,请选择**Azure Blob 存储**或**Amazon S3** 并填写必需的详细信息。

    注意

    如果您使用的是 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 的网关端点

  9. 单击**测试存储设置**。

  10. 单击**保存设置**。

允许网络访问

如果您已在存储帐户上配置了防火墙规则,请确保已允许访问迁移目标的 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
    }
  }
}

注意

确保对type使用GITHUB_ARCHIVE

查询变量描述
name迁移源的名称。此名称仅供您自己参考,因此您可以使用任何字符串。
ownerId您在 GitHub Enterprise Cloud 上的组织的组织 ID。
urlGitHub 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 中启动两次“迁移”:一次用于生成存储库 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",
  // ...
}

更多信息,请参阅“获取组织迁移状态”。

注意

如果您的迁移变为failed状态而不是exported状态,请尝试重新启动迁移。如果迁移反复失败,我们建议使用ghe-migrator而不是 API 生成存档。

按照“从您的企业导出迁移数据”中的步骤操作,每次只添加一个仓库到迁移中。流程结束后,您将拥有一个包含 Git 源代码和元数据的单个迁移归档文件,然后您可以转到本文的步骤 6。

迁移的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 将返回一个302 Found响应,其中包含一个Location头,重定向到可下载归档文件所在的URL。下载两个文件:一个用于 Git 源代码,另一个用于元数据。

更多信息,请参见“下载组织迁移归档”。

两个迁移完成后,并且您已下载归档文件后,您可以进入下一步。

步骤 6:上传迁移归档

要将您的数据导入 GitHub Enterprise Cloud,您必须使用我们的 GraphQL API 将每个仓库的两个归档文件(Git 源代码和元数据)从您的机器传输到 GitHub。

如果您使用的是 GitHub Enterprise Server 3.7 或更低版本,则必须首先为 GitHub 可访问的归档文件生成 URL。大多数客户选择将归档文件上传到云提供商的 Blob 存储服务(例如 Amazon S3 或 Azure Blob Storage),然后为每个文件生成一个短期 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
    }
  }
}
查询变量描述
sourceId您的迁移源id,来自createMigrationSource 变异。
ownerId您在 GitHub Enterprise Cloud 上的组织的组织 ID。
repositoryName自定义的唯一仓库名称,目前 GitHub Enterprise Cloud 上您的组织拥有的任何仓库都不使用此名称。迁移完成后或停止时,将在该仓库中创建一个错误日志问题。
continueOnError迁移设置,允许迁移在遇到不会导致迁移失败的错误时继续进行。必须为truefalse。我们强烈建议将continueOnError设置为true,以便除非导入程序无法移动 Git 源代码或导入程序已断开连接且无法重新连接以完成迁移,否则您的迁移将继续进行。
githubPat您在 GitHub Enterprise Cloud 上的目标组织的个人访问令牌。
accessToken您的源的个人访问令牌。
targetRepoVisibility新仓库的可见性。必须为privatepublicinternal。如果未设置,则您的仓库将作为私有仓库迁移。
gitArchiveUrlGitHub Enterprise Cloud 可访问的 Git 源代码归档文件的 URL。
metadataArchiveUrlGitHub Enterprise Cloud 可访问的元数据归档文件的 URL。
sourceRepositoryUrl您在 GitHub Enterprise Server 实例上仓库的 URL。这是必需的,但 GitHub Enterprise Cloud 不会直接与您的 GitHub Enterprise Server 实例通信。

有关个人访问令牌要求,请参见“管理 GitHub 产品之间迁移的访问权限”。

在下一步中,您将使用startRepositoryMigration 变异返回的迁移 ID 来检查迁移状态。

步骤 8:检查迁移状态

要检测任何迁移失败并确保您的迁移正在运行,您可以使用getMigration 查询检查您的迁移状态。您还可以使用getMigrations检查多个迁移的状态。

getMigration 查询将返回一个状态,让您知道迁移是queuedin progressfailed还是completed。如果您的迁移失败,导入程序将提供失败原因。

getMigration 查询

query (
  $id: ID!
){
  node( id: $id ) {
    ... on Migration {
      id
      sourceUrl
      migrationSource {
        name
      }
      state
      failureReason
    }
  }
}
查询变量描述
idstartRepositoryMigration 变异返回的迁移id

步骤 9:验证您的迁移并检查错误日志

要完成迁移,我们建议您检查“迁移日志”问题。此问题是在 GitHub 的目标仓库中创建的。

Screenshot of an issue with the title "Migration Log." The second comment in the issue includes logs for a migration.

最后,我们建议您审查迁移后的仓库以进行健全性检查。

步骤 1:安装 GitHub CLI 的 GEI 扩展

如果这是您的第一次迁移,您需要安装 GitHub CLI 的 GEI 扩展。有关 GitHub CLI 的更多信息,请参见“关于 GitHub CLI”。

或者,您可以从github/gh-gei 仓库的发行页面下载独立二进制文件。您可以直接运行二进制文件,无需gh前缀。

  1. 安装 GitHub CLI。有关 GitHub CLI 的安装说明,请参见GitHub CLI 仓库

    注意

    您需要 GitHub CLI 2.4.0 或更高版本。您可以使用gh --version命令检查您安装的版本。

  2. 安装 GEI 扩展。

    Shell
    gh extension install github/gh-gei
    

任何时候您需要 GEI 扩展的帮助,您都可以使用命令中的--help标志。例如,gh gei --help将列出所有可用的命令,而gh gei migrate-repo --help将列出migrate-repo命令可用的所有选项。

步骤 2:更新 GitHub CLI 的 GEI 扩展

GEI 扩展每周更新一次。为确保您使用的是最新版本,请更新扩展。

gh extension upgrade github/gh-gei

步骤 3:设置环境变量

在您可以使用 GEI 扩展迁移到 GitHub Enterprise Cloud 之前,您必须创建可以访问源组织和目标组织的个人访问令牌,然后将个人访问令牌设置为环境变量。

  1. 创建并记录一个个人访问令牌(经典),用于在 GitHub Enterprise Cloud 上对目标组织进行身份验证,确保该令牌满足所有要求。更多信息,请参阅“GitHub 产品之间迁移的访问管理”。

  2. 创建并记录一个个人访问令牌,用于对源组织进行身份验证,确保此令牌也满足所有相同的要求。

  3. 设置个人访问令牌的环境变量,将以下命令中的 TOKEN 替换为您上面记录的个人访问令牌。对目标组织使用GH_PAT,对源组织使用GH_SOURCE_PAT

    • 如果您使用的是 Terminal,请使用export命令。

      Shell
      export GH_PAT="TOKEN"
      export GH_SOURCE_PAT="TOKEN"
      
    • 如果您使用的是 PowerShell,请使用$env命令。

      Shell
      $env:GH_PAT="TOKEN"
      $env:GH_SOURCE_PAT="TOKEN"
      
  4. 如果您要使用数据驻留迁移到 GitHub Enterprise Cloud,为了方便起见,请为您的企业的**基本 API URL**设置一个环境变量。例如

    Shell
    export TARGET_API_URL="https://api.octocorp.ghe.com"
    

    您将在使用 GitHub CLI 运行的命令中使用--target-api-url选项使用此变量。

步骤 4:设置 Blob 存储

由于许多 GitHub Enterprise Server 实例位于防火墙之后,因此我们使用 Blob 存储作为存储 GitHub 可以访问的数据的中间位置。

首先,您必须使用受支持的云提供商设置 Blob 存储。然后,您必须在管理控制台或 GitHub CLI 中配置存储提供商的凭据。

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

GitHub CLI 支持以下 Blob 存储提供商

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

设置 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 存储中删除您的存档。为了降低存储成本,我们建议您在一段时间后配置存档的自动删除。更多信息,请参阅 Microsoft Docs 中的通过自动管理数据生命周期来优化成本

配置您的 Blob 存储凭据

在您使用受支持的云提供商设置 Blob 存储后,您必须在 GitHub 中配置存储提供商的凭据。

  • 如果您使用的是 GitHub Enterprise Server 3.8 或更高版本,请在管理控制台中配置您的凭据。
  • 如果您使用的是 GitHub Enterprise Server 3.7 或更低版本,请在 GitHub CLI 中配置凭据。

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

注意

只有在您使用 GitHub Enterprise Server 3.8 或更高版本时,才需要在管理控制台中配置 Blob 存储。如果您使用的是 3.7 或更低版本,请改在 GitHub CLI 中配置您的凭据。

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

  1. 在 GitHub Enterprise Server 上的管理帐户中,单击任何页面右上角的.

  2. 如果您尚未进入“站点管理员”页面,请单击左上角的**站点管理员**。

  3. 在“站点管理员”侧边栏中,单击**管理控制台**。

  4. 登录管理控制台。

  5. 在顶部导航栏中,单击**设置**。

  6. 在**迁移**下,单击**启用 GitHub 迁移**。

  7. 可选地,要导入为 GitHub Actions 配置的存储设置,请选择**从 Actions 复制存储设置**。更多信息,请参阅“使用 Azure Blob 存储启用 GitHub Actions”和“使用 Amazon S3 存储启用 GitHub Actions”。

    注意

    复制存储设置后,您可能仍需要更新云存储帐户的配置才能与 GitHub Enterprise Importer 配合使用。特别是,您必须确保 GitHub 的 IP 地址已列入允许列表。更多信息,请参阅“GitHub 产品之间迁移的访问管理”。

  8. 如果您不从 GitHub Actions 导入存储设置,请选择**Azure Blob 存储**或**Amazon S3** 并填写必需的详细信息。

    注意

    如果您使用的是 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 的网关端点

  9. 单击**测试存储设置**。

  10. 单击**保存设置**。

在 GitHub CLI 中配置您的 Blob 存储凭据

注意

只有在您使用 GitHub Enterprise Server 3.7 或更低版本时,才需要在 GitHub CLI 中配置您的 Blob 存储凭据。如果您使用的是 3.8 或更高版本,请改在管理控制台中配置 Blob 存储。

如果您在 GitHub CLI 中配置 Blob 存储凭据,则您将无法执行 Git 源代码或元数据导出超过 2GB 的迁移。要执行这些迁移,请升级到 GitHub Enterprise Server 3.8 或更高版本。

在 GitHub CLI 中配置 AWS S3 凭据

准备好运行迁移时,您需要向 GitHub CLI 提供您的 AWS 凭据:区域、访问密钥、秘密密钥和会话令牌(如果需要)。您可以将它们作为参数传递,也可以设置名为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的环境变量传递。

允许网络访问

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

步骤 5:生成迁移脚本

如果您想一次将多个仓库迁移到 GitHub Enterprise Cloud,请使用 GitHub CLI 生成迁移脚本。生成的脚本将包含迁移命令列表,每个仓库一个。

注意

生成脚本会输出一个 PowerShell 脚本。如果您使用的是 Terminal,则需要使用.ps1文件扩展名输出脚本,并为MacLinux安装 PowerShell 以运行它。

如果您只想迁移一个仓库,请跳到下一步。

生成迁移脚本

您必须从能够访问 GitHub Enterprise Server 实例 API 的计算机执行此步骤。如果您能够从浏览器访问您的实例,则该计算机具有正确的访问权限。

要生成迁移脚本,请运行gh gei generate-script命令。

对于 GitHub Enterprise Server 3.8 或更高版本,或者如果您使用的是 3.7 或更低版本且使用 Azure Blob Storage,请使用以下标志

Shell
gh gei generate-script --github-source-org SOURCE \
  --github-target-org DESTINATION \
  --output FILENAME \
  --ghes-api-url GHES-API-URL

如果您使用的是 GitHub Enterprise Server 3.7 或更低版本且使用 AWS S3,请使用以下标志

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

占位符

将上述命令中的占位符替换为以下值。

占位符
SOURCE源组织的名称
DESTINATION目标组织的名称
FILENAME生成的迁移脚本的文件名

如果您使用的是终端,请使用.ps1文件扩展名,因为生成的脚本需要 PowerShell 才能运行。您可以为MacLinux安装 PowerShell。
GHES-API-URLGitHub Enterprise Server 实例 API 的 URL,例如https://myghes.com/api/v3
AWS-BUCKET-NAMEAWS S3 存储桶的名称

附加参数

参数描述
--target-api-url TARGET-API-URL如果您迁移到 GHE.com,请添加--target-api-url TARGET-API-URL,其中 TARGET-API-URL 是您企业子域的基本 API URL。例如:https://api.octocorp.ghe.com
--no-ssl-verify如果您的 GitHub Enterprise Server 实例使用自签名或无效的 SSL 证书,请使用--no-ssl-verify标志。使用此标志,GitHub CLI 只会在从您的实例提取数据时跳过验证 SSL 证书。所有其他调用都将验证 SSL。
--download-migration-logs下载每个迁移存储库的迁移日志。有关迁移日志的更多信息,请参阅“访问 GitHub Enterprise Importer 的迁移日志”。

查看迁移脚本

生成脚本后,请查看该文件,并可选择编辑脚本。

  • 如果您不想迁移任何存储库,请删除或注释掉相应的行。
  • 如果您希望任何存储库在目标组织中具有不同的名称,请更新相应--target-repo标志的值。
  • 如果您想更改新存储库的可见性,请更新相应--target-repo-visibility标志的值。默认情况下,脚本设置与源存储库相同的可见性。

如果您的存储库的发布数据超过 10 GB,则无法迁移发布数据。使用--skip-releases标志迁移没有发布数据的存储库。

如果您将 GEI 下载为独立二进制文件而不是 GitHub CLI 的扩展程序,则需要更新生成的脚本以运行二进制文件而不是gh gei

步骤 6:迁移存储库

您可以使用迁移脚本迁移多个存储库,也可以使用gh gei migrate-repo命令迁移单个存储库。

迁移存储库时,GitHub CLI 的 GEI 扩展程序将执行以下步骤

  1. 连接到您的 GitHub Enterprise Server 实例,并为每个存储库生成两个迁移存档,一个用于 Git 源,另一个用于元数据
  2. 将迁移存档上传到您选择的 Blob 存储提供程序
  3. 使用存储在 Blob 存储提供程序中的存档 URL 在 GitHub Enterprise Cloud 中启动迁移
  4. 从本地计算机删除迁移存档

迁移多个存储库

如果您是从 GitHub Enterprise Server 3.7 或更早版本迁移,则在运行脚本之前,必须设置其他环境变量以对 Blob 存储提供程序进行身份验证。

  • 对于 Azure Blob Storage,请将AZURE_STORAGE_CONNECTION_STRING设置为 Azure 存储帐户的连接字符串。

    仅支持使用存储帐户访问密钥的连接字符串。不支持使用共享访问签名 (SAS) 的连接字符串。有关存储帐户访问密钥的更多信息,请参阅 Azure 文档中的管理存储帐户访问密钥

  • 对于 AWS S3,请设置以下环境变量。

    • AWS_ACCESS_KEY_ID:存储桶的访问密钥 ID
    • AWS_SECRET_ACCESS_KEY:存储桶的密钥
    • AWS_REGION:存储桶所在的 AWS 区域
    • AWS_SESSION_TOKEN:如果您使用的是 AWS 临时凭据,则为会话令牌(请参阅 AWS 文档中的使用临时凭据与 AWS 资源

要迁移多个存储库,请运行您上面生成的脚本。在下面的命令中,将 FILENAME 替换为您在生成脚本时提供的文件名。

  • 如果您使用的是终端,请使用./

    Shell
    ./FILENAME
    
  • 如果您使用的是 PowerShell,请使用.\

    Shell
    .\FILENAME
    

迁移单个存储库

您必须从能够访问 GitHub Enterprise Server 实例 API 的计算机执行此步骤。如果您能够从浏览器访问您的实例,则该计算机具有正确的访问权限。

要迁移单个存储库,请使用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 或更早版本迁移,并使用 Azure Blob Storage 作为 Blob 存储提供程序,请使用以下标志进行身份验证

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 或更早版本迁移,并使用 Amazon S3 作为 Blob 存储提供程序,请使用以下标志进行身份验证

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"

占位符

将上述命令中的占位符替换为以下值。

占位符
SOURCE源组织的名称
CURRENT-NAME您要迁移的存储库的名称
DESTINATION目标组织的名称
NEW-NAME您希望迁移的存储库具有的名称
GHES-API-URLGitHub Enterprise Server 实例 API 的 URL,例如https://myghes.com/api/v3
AZURE_STORAGE_CONNECTION_STRINGAzure 存储帐户的连接字符串。

请务必引用包含 shell 可能会解释的其他字符的连接字符串。
AWS-BUCKET-NAMEAWS S3 存储桶的名称

附加参数

参数描述
--target-api-url TARGET-API-URL如果您迁移到 GHE.com,请添加--target-api-url TARGET-API-URL,其中 TARGET-API-URL 是您企业子域的基本 API URL。例如:https://api.octocorp.ghe.com
--no-ssl-verify如果您的 GitHub Enterprise Server 实例使用自签名或无效的 SSL 证书,请使用--no-ssl-verify标志。使用此标志,GitHub CLI 只会在从您的实例提取数据时跳过验证 SSL 证书。所有其他调用都将验证 SSL。
--skip-releases如果您的存储库的发布数据超过 10 GB,则无法迁移发布数据。使用--skip-releases标志迁移没有发布数据的存储库。
--target-repo-visibility TARGET-VISIBILITY存储库默认以私有可见性迁移。要设置可见性,您可以添加--target-repo-visibility标志,指定privatepublicinternal。如果您迁移到具有托管用户的企业,则公共存储库不可用。

中止迁移

如果您想取消迁移,请使用abort-migration命令,将 MIGRATION-ID 替换为migrate-repo返回的 ID。

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

步骤 7:验证迁移并检查错误日志

迁移完成后,我们建议您查看迁移日志。有关更多信息,请参阅“访问 GitHub Enterprise Importer 的迁移日志”。

我们建议您查看迁移的存储库以进行完整性检查。

迁移完成后,我们建议您从存储容器中删除存档。如果您计划完成其他迁移,请删除 ADO2GH 扩展程序放入存储容器中的存档。如果您已完成迁移,则可以删除整个容器。