关于使用 GitHub Enterprise Importer
进行存储库迁移
可以使用 GitHub CLI 或 API 运行迁移。
GitHub CLI 可简化迁移过程,建议大多数客户使用。 具有大量自定义需求的高级客户可以使用 API 构建自己的与 GitHub Enterprise Importer 的集成。
如果选择使用 API,则需要编写自己的脚本或使用 HTTP 客户端(如 Insomnia)。 可以在“REST API 入门”和“使用 GraphQL 建立调用”中详细了解如何开始使用 GitHub 的 API。
若要使用 API 将存储库从 GitHub Enterprise Server 迁移到 GitHub Enterprise Cloud,将执行以下操作:
- 为源组织和目标组织创建 personal access token
- 获取目标组织在 GitHub Enterprise Cloud 上的
ownerId
- 通过 GitHub 的 GraphQL API 设置迁移源,确定要从何处迁移
- 对于要迁移的每个存储库重复以下步骤。
- 使用 你的 GitHub Enterprise Server 实例 上的 REST API 为存储库生成迁移存档
- 将迁移存档上传到 GitHub 可以访问的位置
- 使用 GitHub 的 GraphQL API 开始迁移,并传入存档 URL
- 通过 GraphQL API 检查迁移状态
- 验证迁移并检查错误日志
若要查看使用 API 的说明,请使用页面顶部的工具切换器。
若要查看使用 GitHub CLI 的说明,请使用页面顶部的工具切换器。
先决条件
- 强烈建议执行迁移的试运行,然后在不久之后完成生产迁移。 要了解试运行的详细信息,请参阅“在 GitHub 产品之间迁移的概述”。
- 确保了解将要迁移的数据以及导入程序已知的支持限制。有关详细信息,请参阅“关于 GitHub 产品之间的迁移”。
- 虽然并非必需,但建议在生产迁移期间停止工作。 Importer 不支持增量迁移,因此迁移期间发生的任何更改都不会迁移。 如果选择在生产迁移期间不停止工作,需要手动迁移这些更改。
- 在源组织和目标组织中,你必须是组织所有者或被授予迁移者角色。 有关详细信息,请参阅“管理 GitHub 产品之间迁移的访问权限”。
- 如果使用 GitHub Enterprise Server 3.8 或更高版本,则需要具有对 管理控制台 的访问权限才能为导出的存档配置 Blob 存储。
步骤 1。 创建 personal access token
- 创建并记录一个 personal access token (classic),用于在 GitHub Enterprise Cloud 上为目标组织进行身份验证,确保令牌满足所有要求。 有关详细信息,请参阅“管理 GitHub 产品之间迁移的访问权限”。
- 创建并记录一个 personal access token,用于对源组织进行身份验证的,确保此令牌也满足所有相同的要求。
步骤 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 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/*"
]
}
]
}
注意:迁移完成后,GitHub Enterprise Importer 不会从 AWS 中删除存档。 为了降低存储成本,建议配置在一段时间后自动删除存档。 有关详细信息,请参阅 AWS 文档中的 Bucket 生命周期配置。
设置 Azure Blob 存储帐户
在 Azure 中,创建存储帐户并记下连接字符串。 有关详细信息,请参阅 Microsoft Docs 中的管理存储帐户访问密钥。
注意:迁移完成后,GitHub Enterprise Importer 不会从 Azure Blob 存储中删除存档。 为了降低存储成本,建议配置为在一段时间后自动删除存档。 有关详细信息,请参阅 Microsoft Docs 中的通过自动管理数据生命周期来优化成本。
在 你的 GitHub Enterprise Server 实例 的 管理控制台 中配置 blob 存储
设置 AWS S3 存储桶或 Azure Blob 存储存储帐户后,请在 你的 GitHub Enterprise Server 实例 的 管理控制台 中配置 Blob 存储。 有关 管理控制台 的详细信息,请参阅“从管理控制台管理实例”。
-
在 GitHub Enterprise Server 上的管理帐户中,在任一页面的右上角,单击“”。
-
如果你还没有进入“站点管理员”页面,请单击左上角的“站点管理员”。1. 在“ 站点管理”边栏中,单击“管理控制台”。
-
登录到 管理控制台。
-
在顶部导航栏中,单击“设置”。
-
在“迁移”下,单击“启用 GitHub 迁移” 。
-
(可选)要导入为 GitHub Actions 配置的存储设置,请选择“从 Actions 复制存储设置”。 有关详细信息,请参阅“使用 Azure Blob 存储启用 GitHub Actions”和“使用 Amazon S3 存储启用 GitHub Actions”。
注意****:复制存储设置后,仍可能需要更新云存储帐户的配置才能与 GitHub Enterprise Importer 一起使用。 尤其是务必要将 GitHub 的 IP 地址加入允许列表。 有关详细信息,请参阅“管理 GitHub 产品之间迁移的访问权限”。
-
如果不从 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 的网关端点。 -
单击“测试存储设置”。
-
单击“保存设置”。
步骤 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
}
}
}
注意:请确保将 GITHUB_ARCHIVE
用于 type
。
查询变量 | 说明 |
---|---|
name | 迁移源的名称。 此名称仅供你自己参考,因此可以使用任何字符串。 |
ownerId | GitHub Enterprise Cloud 上组织的组织 ID。 |
url | 你的 GitHub Enterprise Server 实例 的 URL。 无需从 GitHub Enterprise Cloud 访问此 URL。 |
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 将返回带有 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
}
}
}
查询变量 | 说明 |
---|---|
sourceId | 从 createMigrationSource 突变返回的迁移源 id 。 |
ownerId | 组织在 GitHub Enterprise Cloud 上的组织 ID。 |
repositoryName | 组织在 GitHub Enterprise Cloud 上拥有的任何存储库当前未使用的自定义唯一存储库名称。 迁移完成或停止时,将在此存储库中创建一个错误记录问题。 |
continueOnError | 迁移设置,允许在遇到不会导致迁移失败的错误时继续迁移。 必须为 true 或 false 。 强烈建议将 continueOnError 设置为 true ,以便继续迁移,除非 Importer 无法移动 Git 源,或 Importer 已断开连接且无法重新连接以完成迁移。 |
githubPat | 目标组织在 GitHub Enterprise Cloud 上的 personal access token。 |
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 产品之间迁移的访问权限”。
在下一步中,将使用从 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
}
}
}
查询变量 | 说明 |
---|---|
id | startRepositoryMigration 突变返回的迁移的 id 。 |
步骤 9:验证迁移并检查错误日志
要完成迁移,建议检查“迁移日志”问题。 此问题在目标存储库中的 GitHub 上创建。
最后,建议查看已迁移的存储库以进行完整性检查。
步骤 1:安装 GEI extension of the GitHub CLI
如果这是第一次迁移,需要安装 GEI extension of the GitHub CLI。 有关 GitHub CLI 的详细信息,请参阅“关于 GitHub CLI”。
此外,也可以从 github/gh-gei
存储库的版本页面下载一个独立的二进制文件。 可以直接运行此二进制文件,无需使用前缀 gh
。
-
安装 GitHub CLI。 有关 GitHub CLI 的安装说明,请参阅 GitHub CLI 存储库。
注意:需要 GitHub CLI 版本 2.4.0 或更高版本。 可以使用
gh --version
命令检查已安装的版本。 -
安装 GEI extension。
Shell gh extension install github/gh-gei
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 之前,必须创建可以访问源和目标组织的 personal access token,然后将 personal access token 设置为环境变量。
-
创建并记录一个 personal access token (classic),用于在 GitHub Enterprise Cloud 上为目标组织进行身份验证,确保令牌满足所有要求。 有关详细信息,请参阅“管理 GitHub 产品之间迁移的访问权限”。
-
创建并记录一个 personal access token,用于对源组织进行身份验证的,确保此令牌也满足所有相同的要求。
-
为 personal access token 设置环境变量,将以下命令中的 TOKEN 替换为上面记录的 personal access token。 将
GH_PAT
用于目标组织,并将GH_SOURCE_PAT
用于源组织。-
如果使用终端,请使用
export
命令。Shell export GH_PAT="TOKEN" export GH_SOURCE_PAT="TOKEN"
export GH_PAT="TOKEN" export GH_SOURCE_PAT="TOKEN"
-
如果使用 PowerShell,请使用
$env
命令。Shell $env:GH_PAT="TOKEN" $env:GH_SOURCE_PAT="TOKEN"
$env:GH_PAT="TOKEN" $env:GH_SOURCE_PAT="TOKEN"
-
步骤 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 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/*"
]
}
]
}
注意:迁移完成后,GitHub Enterprise Importer 不会从 AWS 中删除存档。 为了降低存储成本,建议配置在一段时间后自动删除存档。 有关详细信息,请参阅 AWS 文档中的 Bucket 生命周期配置。
设置 Azure Blob 存储存储帐户
在 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 存储。 有关 管理控制台 的详细信息,请参阅“从管理控制台管理实例”。
-
在 GitHub Enterprise Server 上的管理帐户中,在任一页面的右上角,单击“”。
-
如果你还没有进入“站点管理员”页面,请单击左上角的“站点管理员”。1. 在“ 站点管理”边栏中,单击“管理控制台”。
-
登录到 管理控制台。
-
在顶部导航栏中,单击“设置”。
-
在“迁移”下,单击“启用 GitHub 迁移” 。
-
(可选)要导入为 GitHub Actions 配置的存储设置,请选择“从 Actions 复制存储设置”。 有关详细信息,请参阅“使用 Azure Blob 存储启用 GitHub Actions”和“使用 Amazon S3 存储启用 GitHub Actions”。
注意****:复制存储设置后,仍可能需要更新云存储帐户的配置才能与 GitHub Enterprise Importer 一起使用。 尤其是务必要将 GitHub 的 IP 地址加入允许列表。 有关详细信息,请参阅“管理 GitHub 产品之间迁移的访问权限”。
-
如果不从 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 的网关端点。 -
单击“测试存储设置”。
-
单击“保存设置”。
在 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_REGION
、AWS_ACCESS_KEY_ID
、AWS_SECRET_ACCESS_KEY
和 AWS_SESSION_TOKEN
的环境变量。
你还需要使用 --aws-bucket-name
参数传入 S3 Bucket 的名称。
在 GitHub CLI 中配置 Azure Blob 存储帐户凭据
准备好运行迁移时,可以将连接字符串作为参数传递到 GitHub CLI,或使用名为 AZURE_STORAGE_CONNECTION_STRING
的环境变量将其传入。
步骤 5:生成迁移脚本
如果要一次性将多个存储库迁移到 GitHub Enterprise Cloud,请使用 GitHub CLI 生成迁移脚本。 生成的脚本将包含迁移命令的列表(每个存储库一个)。
如果要迁移单个存储库,请跳到下一步。
生成迁移脚本
必须在可以访问 你的 GitHub Enterprise Server 实例 的 API 的计算机上执行此步骤。 如果可以从浏览器访问实例,那么计算机具有正确的访问权限。
若要生成迁移脚本,请运行 gh gei generate-script
命令。
对于 GitHub Enterprise Server 3.8 或更高版本,或者如果将 3.7 或更低版本与 Azure Blob 存储配合使用,请使用以下标志:
gh gei generate-script --github-source-org SOURCE \ --github-target-org DESTINATION \ --output FILENAME \ --ghes-api-url GHES-API-URL
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 配合使用,请使用以下标志:
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
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 的迁移日志”。
将上述命令中的占位符替换为以下值。
占位符 | 值 |
---|---|
源 | 源组织名称 |
目标 | 目标组织的名称 |
FILENAME | 生成的迁移脚本的文件名 如果使用终端,请使用 .ps1 文件扩展名,因为生成的脚本需要 PowerShell 才能运行。 可以安装适用于 Mac 或 Linux 的 PowerShell。 |
GHES-API-URL | 你的 GitHub Enterprise Server 实例 的 API 的 URL,如 https://myghes.com/api/v3 |
AWS-BUCKET-NAME | AWS S3 桶的桶名称 |
查看迁移脚本
生成脚本后,查看文件,并根据需要编辑脚本。
- 如果有任何不想迁移的存储库,请删除或注释禁止相应的行。
- 如果希望任何存储库在目标组织中具有不同的名称,请更新相应
--target-repo
标志的值。 - 如果要更改新存储库的可见性,请更新相应的
--target-repo-visibility
标志的值。 默认情况下,脚本设置与源存储库相同的可见性。
注意:如果存储库的发布数据超过 10 GB,则无法迁移发布。 使用 --skip-releases
标志即可在不迁移发布的情况下迁移存储库。
如果将 GEI 作为一个独立的二进制文件而不是 GitHub CLI 的一个扩展下载,则需要更新所生成的脚本,以运行此二进制文件而不是 gh gei
。
步骤 6:迁移存储库
可以使用迁移脚本迁移多个存储库,也可以使用 gh gei migrate-repo
命令迁移单个存储库。
迁移存储库时,GEI extension of the GitHub CLI 将执行以下步骤:
- 连接到 你的 GitHub Enterprise Server 实例 并为每个存储库生成两个迁移存档,一个用于 Git 源,一个用于元数据
- 将迁移存档上传到所选的 blob 存储提供程序
- 通过使用 blob 存储提供程序存储的存档 URL 在 GitHub Enterprise Cloud 中开始迁移
- 从本地计算机中删除迁移存档
迁移多个存储库
如果要从 GitHub Enterprise Server 3.7 或更早版本迁移,在运行脚本之前,必须设置其他环境变量以向 Blob 存储提供程序进行身份验证。
-
对于 Azure Blob 存储,请将
AZURE_STORAGE_CONNECTION_STRING
设置为 Azure 存储帐户的连接字符串。仅支持使用存储帐户访问密钥的连接字符串。 不支持使用共享访问签名 (SAS) 的连接字符串。 有关存储帐户访问密钥的详细信息,请参阅 Azure 文档中的管理存储帐户访问密钥。
-
对于 AWS S3,请设置以下环境变量。
AWS_ACCESS_KEY_ID
:存储桶的访问密钥 IDAWS_SECRET_ACCESS_KEY
:存储桶的密钥AWS_REGION
:桶所在的 AWS 区域AWS_SESSION_TOKEN
:会话令牌(如果使用的是 AWS 临时凭据)(请参阅 AWS 文档中的将临时凭据用于 AWS 资源)
要迁移多个存储库,请运行上面生成的脚本。 将以下命令中的 FILENAME 替换为生成脚本时提供的文件名。
-
如果使用终端,请使用
./
。Shell ./FILENAME
./FILENAME
-
如果使用 PowerShell,请使用
.\
。Shell .\FILENAME
.\FILENAME
迁移单个存储库
必须在可以访问 你的 GitHub Enterprise Server 实例 的 API 的计算机上执行此步骤。 如果可以从浏览器访问实例,那么计算机具有正确的访问权限。
要迁移单个存储库,请使用 gh gei migrate-repo
命令。
如果使用 GitHub Enterprise Server 3.8 或更高版本,请使用以下标志:
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
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 存储作为 Blob 存储提供程序,请使用以下标志进行身份验证:
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"
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 存储提供程序,请使用以下标志进行身份验证:
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"
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
标志即可在不迁移发布的情况下迁移存储库。
默认情况下,存储库都以专用可见性进行迁移。 若要设置可见性,可以添加 --target-repo-visibility
标志,以指定 private
、public
或 internal
。 如果要迁移到 具有托管用户的企业,则公共存储库不可用。
将上述命令中的占位符替换为以下值。
占位符 | 值 |
---|---|
源 | 源组织名称 |
CURRENT-NAME | 要迁移的存储库的名称 |
目标 | 目标组织的名称 |
NEW-NAME | 希望已迁移的存储库具有的名称 |
GHES-API-URL | 你的 GitHub Enterprise Server 实例 的 API 的 URL,如 https://myghes.com/api/v3 |
AZURE_STORAGE_CONNECTION_STRING | Azure 存储帐户的连接字符串。 请确保为连接字符串加引号,其中包含可能由 shell 解释的字符。 |
AWS-BUCKET-NAME | AWS S3 桶的桶名称 |
如果要取消迁移,请使用 abort-migration
命令,将 MIGRATION-ID 替换为从 migrate-repo
返回的 ID。
gh gei abort-migration --migration-id MIGRATION-ID
gh gei abort-migration --migration-id MIGRATION-ID
步骤 7:验证迁移并检查错误日志
迁移完成后,建议查看迁移日志。 有关详细信息,请参阅“访问 GitHub Enterprise Importer 的迁移日志”。
建议查看已迁移的存储库以进行完整性检查。
迁移完成后,建议从存储容器中删除存档。 如果计划完成其他迁移,请删除 ADO2GH extension 放入存储容器中的存档。 如果已完成迁移,则可以删除整个容器。