准备迁移的数据
-
使用
scp
命令,将从源实例或组织生成的迁移归档文件复制到您的 GitHub Enterprise Server 目标scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/
-
SSH 登录到您的目标 GitHub Enterprise Server 实例。有关更多信息,请参阅“访问管理 Shell (SSH)”。
ssh -p 122 admin@HOSTNAME
-
使用
ghe-migrator prepare
命令准备要在目标实例上导入的归档文件,并为您生成一个新的迁移 GUID,以便在后续步骤中使用ghe-migrator prepare /home/admin/MIGRATION-GUID.tar.gz
- 要启动新的导入尝试,请再次运行
ghe-migrator prepare
并获取新的迁移 GUID。 - 要指定迁移文件应在何处暂存,请在命令后面附加
--staging-path=/full/staging/path
。默认为/data/user/tmp
。
- 要启动新的导入尝试,请再次运行
生成迁移冲突列表
-
使用
ghe-migrator conflicts
命令和迁移 GUID 生成 conflicts.csv 文件ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv
- 如果未报告任何冲突,则可以安全地导入数据。
-
如果有冲突,请使用
scp
命令将 conflicts.csv 复制到您的本地计算机scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop
-
继续执行“解决迁移冲突或设置自定义映射”。
查看迁移冲突
- 使用文本编辑器或 与 CSV 兼容的电子表格软件打开 conflicts.csv。
- 根据以下示例和参考表中的指导,查看 conflicts.csv 文件,以确保在导入时将执行正确的操作。
conflicts.csv 文件包含一个 迁移映射,其中列出了冲突和建议的操作。迁移映射列出了从源迁移的数据以及如何将数据应用于目标。
model_name | source_url | target_url | recommended_action |
---|---|---|---|
user | https://example-gh.source/octocat | https://example-gh.target/octocat | map |
organization | https://example-gh.source/octo-org | https://example-gh.target/octo-org | map |
repository | https://example-gh.source/octo-org/widgets | https://example-gh.target/octo-org/widgets | rename |
team | https://example-gh.source/orgs/octo-org/teams/admins | https://example-gh.target/orgs/octo-org/teams/admins | merge |
project | https://example-gh.source/octo-org/widgets/projects/1 | https://example-gh.target/octo-org/projects/1 | merge |
conflicts.csv 中的每一行都提供以下信息
名称 | 描述 |
---|---|
model_name | 正在更改的数据类型。 |
source_url | 数据的源 URL。 |
target_url | 数据的预期目标 URL。 |
recommended_action | 导入数据时 ghe-migrator 将采取的首选操作。 |
每种记录类型的可能映射
在传输数据时,ghe-migrator
可以执行多种不同的映射操作
action | 描述 | 适用的模型 |
---|---|---|
import | (默认) 将源数据导入目标。 | 所有记录类型 |
map | 不根据源数据创建新的模型,而是使用目标中现有的记录。这对于将存储库导入现有组织或将目标中的用户标识映射到源中的用户标识很有用。 | 用户、组织、项目 |
rename | 将源数据重命名,然后复制到目标。 | 用户、组织、存储库、项目 |
map_or_rename | 如果目标存在,则映射到该目标。否则,重命名导入的模型。 | 用户 |
merge | 源数据与目标实例上的现有数据合并。 | 团队,项目 |
我们强烈建议您查看conflicts.csv文件并使用ghe-migrator audit
命令确保正在采取正确的操作。 如果一切正常,您可以继续。
解决迁移冲突或设置自定义映射
如果您认为ghe-migrator
将执行不正确的更改,可以通过更改conflicts.csv中的数据进行更正。您可以更改conflicts.csv中任何行的内容。
例如,假设您注意到源实例中的octocat
用户正在映射到目标实例上的octocat
。
model_name | source_url | target_url | recommended_action |
---|---|---|---|
user | https://example-gh.source/octocat | https://example-gh.target/octocat | map |
您可以选择将该用户映射到目标实例上的其他用户。假设您知道octocat
实际上应该映射到目标实例上的monalisa
。您可以更改conflicts.csv中的target_url
列以引用monalisa
。
model_name | source_url | target_url | recommended_action |
---|---|---|---|
user | https://example-gh.source/octocat | https://example-gh.target/monalisa | map |
再举一个例子,如果您想将octo-org/widgets
存储库重命名为目标实例上的octo-org/amazing-widgets
,请将target_url
更改为octo-org/amazing-widgets
,并将recommend_action
更改为rename
。
model_name | source_url | target_url | recommended_action |
---|---|---|---|
repository | https://example-gh.source/octo-org/widgets | https://example-gh.target/octo-org/amazing-widgets | rename |
添加自定义映射
迁移期间的一个常见场景是,迁移的用户在目标实例上的用户名与其在源实例上的用户名不同。
给定源实例中的一组用户名和目标实例中的一组用户名,您可以构建一个包含自定义映射的CSV文件,然后将其应用于确保每个用户的用户名及其内容在迁移结束时被正确归属。
您可以使用ghe-migrator audit
命令快速生成一个CSV文件,其中包含以应用自定义映射所需的CSV格式迁移的用户。
ghe-migrator audit -m user -g MIGRATION-GUID > users.csv
现在,您可以编辑该CSV文件并输入要映射或重命名的每个用户的新的URL,然后将第四列更新为map
或rename
,具体取决于情况。
例如,要将用户octocat
重命名为目标实例https://example-gh.target
上的monalisa
,您将创建一个包含以下内容的行
model_name | source_url | target_url | 状态 |
---|---|---|---|
user | https://example-gh.source/octocat | https://example-gh.target/monalisa | rename |
相同的过程可用于为支持自定义映射的每个记录创建映射。有关更多信息,请参阅我们关于记录可能映射的表格。
应用修改后的迁移数据
-
进行更改后,使用
scp
命令将您修改后的conflicts.csv(或任何其他格式正确的映射.csv文件)应用于目标实例。scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/
-
使用
ghe-migrator map
命令重新映射迁移数据,并将修改后的.csv文件的路径和迁移GUID作为参数传递。ghe-migrator map -i conflicts.csv -g MIGRATION-GUID
-
如果
ghe-migrator map -i conflicts.csv -g MIGRATION-GUID
命令报告仍然存在冲突,请再次执行迁移冲突解决过程。
在GitHub Enterprise Server上应用导入的数据
-
SSH 登录到您的目标 GitHub Enterprise Server 实例。有关更多信息,请参阅“访问管理 Shell (SSH)”。
ssh -p 122 admin@HOSTNAME
-
使用
ghe-migrator import
命令开始导入过程。您需要- 您的迁移GUID。有关更多信息,请参阅“准备要导入到GitHub Enterprise Server的迁移数据”。
- 用于身份验证的个人访问令牌。您使用的个人访问令牌仅用于作为站点管理员进行身份验证,不需要任何特定的范围或权限。有关更多信息,请参阅“管理您的个人访问令牌”。
$ ghe-migrator import /home/admin/MIGRATION-GUID.tar.gz -g MIGRATION-GUID -u USERNAME -p TOKEN > Starting GitHub::Migrator > Import 100% complete /
- 要指定迁移文件应在何处暂存,请在命令后面附加
--staging-path=/full/staging/path
。默认为/data/user/tmp
。
查看迁移数据
默认情况下,ghe-migrator audit
返回每条记录。它还允许您按以下条件筛选记录:
- 记录类型。
- 记录的状态。
记录类型与迁移数据中找到的记录类型匹配。
记录类型筛选器
记录类型 | 筛选器名称 |
---|---|
用户 | user |
组织 | organization |
存储库 | repository |
团队 | team |
里程碑 | 里程碑 |
项目(经典) | project |
问题 | 问题 |
问题评论 | issue_comment |
拉取请求 | pull_request |
拉取请求审查 | pull_request_review |
提交评论 | commit_comment |
拉取请求审查评论 | pull_request_review_comment |
发布 | 发布 |
对拉取请求或问题采取的操作 | issue_event |
受保护的分支 | protected_branch |
记录状态筛选器
记录状态 | 描述 |
---|---|
导出 | 该记录将被导出。 |
import | 该记录将被导入。 |
map | 该记录将被映射。 |
rename | 该记录将被重命名。 |
merge | 该记录将被合并。 |
已导出 | 该记录已成功导出。 |
已导入 | 该记录已成功导入。 |
已映射 | 该记录已成功映射。 |
已重命名 | 该记录已成功重命名。 |
已合并 | 该记录已成功合并。 |
导出失败 | 该记录导出失败。 |
导入失败 | 该记录导入失败。 |
映射失败 | 该记录映射失败。 |
重命名失败 | 该记录重命名失败。 |
合并失败 | 该记录合并失败。 |
筛选已审核的记录
使用ghe-migrator audit
命令,您可以使用-m
标志根据记录类型进行筛选。同样,您可以使用-s
标志根据导入状态进行筛选。该命令如下所示:
ghe-migrator audit -m RECORD_TYPE -s STATE -g MIGRATION-GUID
例如,要查看每个成功导入的组织和团队,您将输入:
$ ghe-migrator audit -m organization,team -s mapped,renamed -g MIGRATION-GUID
> model_name,source_url,target_url,state
> organization,https://gh.source/octo-org/,https://ghe.target/octo-org/,renamed
我们强烈建议您审核每个导入失败的记录。 为此,您将输入:
$ ghe-migrator audit -s failed_import,failed_map,failed_rename,failed_merge -g MIGRATION-GUID
> model_name,source_url,target_url,state
> user,https://gh.source/octocat,https://gh.target/octocat,failed
> repository,https://gh.source/octo-org/octo-project,https://ghe.target/octo-org/octo-project,failed
如果您对导入失败有任何疑问,您可以访问GitHub Enterprise 支持与我们联系。
完成GitHub Enterprise Server上的导入
将迁移应用于目标实例并查看迁移后,您将解锁存储库并将其从源实例中删除。在删除源数据之前,我们建议您等待大约两周,以确保一切按预期运行。
解锁目标实例上的存储库
-
SSH连接到GitHub.com。如果您的实例包含多个节点(例如,如果配置了高可用性或地理复制),则SSH连接到主节点。如果您使用集群,则可以SSH连接到任何节点。将HOSTNAME替换为您实例的主机名,或节点的主机名或IP地址。有关更多信息,请参阅“访问管理 Shell (SSH)”。
Shell ssh -p 122 admin@HOSTNAME
ssh -p 122 admin@HOSTNAME
-
使用
ghe-migrator unlock
命令解锁所有导入的存储库。您需要您的迁移GUID。
$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project
警告
如果您的存储库包含使用schedule
触发器的GitHub Actions工作流,则导入后这些工作流将不会自动运行。要再次启动计划的工作流,请向存储库推送提交。有关更多信息,请参阅“触发工作流的事件”。
解锁源实例上的存储库
迁移完成后,您应该解锁源实例上的存储库。
解锁GitHub.com组织上的存储库
要解锁GitHub.com组织上的存储库,您将向迁移解锁端点发送DELETE
请求。您需要
- 用于身份验证的访问令牌
- 迁移的唯一
id
- 要解锁的存储库的名称
curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
-H "Accept: application/vnd.github.wyandotte-preview+json" \
https://api.github.com/orgs/ORG-NAME/migrations/ID/repos/REPO_NAME/lock
从GitHub.com组织中删除存储库
解锁GitHub.com组织的存储库后,您应该使用存储库删除端点删除之前迁移的每个存储库。您需要用于身份验证的访问令牌。
curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
https://api.github.com/repos/ORG-NAME/REPO_NAME
解锁GitHub Enterprise Server实例上的存储库
-
SSH连接到GitHub.com。如果您的实例包含多个节点(例如,如果配置了高可用性或地理复制),则SSH连接到主节点。如果您使用集群,则可以SSH连接到任何节点。将HOSTNAME替换为您实例的主机名,或节点的主机名或IP地址。有关更多信息,请参阅“访问管理 Shell (SSH)”。
Shell ssh -p 122 admin@HOSTNAME
ssh -p 122 admin@HOSTNAME
-
使用
ghe-migrator unlock
命令解锁所有导入的存储库。您需要您的迁移GUID。
$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project