使用企业实时迁移迁移存储库

注意

Enterprise Live Migrations 位于公共预览版，可能会有变动。

提示

按照本指南操作，可以参考企业实时迁移命令行界面参考获取更详细的用法信息。如果遇到错误，请参阅排查从 GitHub Enterprise Server 到 GHE.com 的实时迁移问题。

先决条件

请确保已准备好进行迁移。请参阅“准备从 GitHub Enterprise Server 到 GHE.com 的实时迁移”。

1.创建访问令牌

必须对迁移的源和目标进行personal access token (classic)的身份验证。有关详细说明，请参阅“管理个人访问令牌”。

          **记下这两个令牌**，因为下一步中将需要它们。

在personal access token (classic) 上创建GitHub Enterprise Server，使用以下作用域。
- repo
- admin:org
- admin:repo_hook
- admin:org_hook
在personal access token (classic) 上创建GHE.com，并使用以下作用域。
- repo
- workflow
- admin:org
- admin:repo_hook
- admin:enterprise
如果在目标组织GHE.com上强制实施单一登录，请对GHE.com令牌进行授权。

2. 配置 GitHub Enterprise Server

在执行迁移之前， GitHub Enterprise Server 必须在实例上设置一些配置。这些配置值适用于所有 ELM 迁移。 GitHub Enterprise Server应用新配置时，开发人员可能会遇到短暂的停机时间。

       GitHub Enterprise Server通过 SSH 访问管理程序。 请参阅“[AUTOTITLE](/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh)”。

使用 ghe-config. 设置以下配置变量。

例如：ghe-config app.elm-exporter.enabled true

可变	将此设置为...
`app.elm-exporter.enabled`	`true`
`app.elm.internal-webhooks-enabled`	`true`
`app.elm-exporter.webhooks-loopback-address-enabled`	`true`
`secrets.elm-exporter.migration-target-url`	目标企业的 API URL（例如： `https://api.octocorp.ghe.com`）。

       **不要**在 URL 的末尾包含尾部斜杠。 |

       **如果尚未**启用迁移并在实例上配置 Blob 存储，现在可以对其进行配置。 可以在管理控制台`HOSTNAME/setup/settings`（）的“迁移”部分中检查现有设置。

可以使用以下默认值，这不会引入任何意外的功能。

Shell

ghe-config app.migrations.enabled true

ghe-config app.migrations.enabled true

Shell

ghe-config secrets.migrations.blob-storage-type local-storage

ghe-config secrets.migrations.blob-storage-type local-storage

应用配置。
Shell
```
ghe-config-apply
```
```
ghe-config-apply
```

3.设置所需的环境变量

应用配置后，在开始迁移之前，请设置所需的环境变量。例如：

export API_URL='http://localhost:1738'

重要

复制 API_URL 和 MIGRATION_MANAGER_HMAC_KEY 的值，逐字复制。其他变量特定于你的环境。

可变	所需的值
API_URL	`http://localhost:1738`
MIGRATION_MANAGER_HMAC_KEY	`$（ghe-config secrets.elm-exporter.elm-exporter-hmac-keys）`
MIGRATION_TARGET_URL	目标企业的 API URL（例如： `https://api.octocorp.ghe.com`）。

          **不要**在 URL 的末尾包含尾部斜杠。 |

| 迁移目标标记 (MIGRATION_TARGET_TOKEN) | for personal access token (classic)GHE.com |

这些值中的任何值也可以作为 CLI 标志提供给任何 elm 命令，这将优先于变量。例如： --api-url http://localhost:1738。

4.创建迁移

通过指定源和目标存储库详细信息创建新的迁移。 --pat-name 必须设置为 system-pat 静态值。其他值是特定于您环境的占位符。

注意

target-org可以是新的或现有的。如果目标组织尚不存在，则会在迁移期间创建它。但是，不会迁移来自源组织的设置。

Shell

elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO \
  --target-api GHEC-API-URL \
  --pat-name system-pat

elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO \
  --target-api GHEC-API-URL \
  --pat-name system-pat

例如：

elm migration create \
  --source-org my-ghes-org \
  --source-repo my-ghes-repo \
  --target-org my-dr-org \
  --target-repo my-dr-repo \
  --target-api $MIGRATION_TARGET_URL \
  --pat-name system-pat

可选标志：

--start：如果已准备好立即开始迁移。
--target-visibility：默认情况下，迁移的存储库是使用内部可见性创建的，但可以指定 private。

保存迁移 ID

应会看到如下所示的响应：

{
  "migrationId": "2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9",
  "expiresAt": "2026-02-11T21:49:33.619162159Z"
}

导出 migrationId 为变量，因为下一个命令将需要它。例如：

export MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9'

5.开始迁移

如果尚未启动迁移，请使用刚刚保存的迁移 ID 立即启动它。

Shell

elm migration start --migration-id $MIGRATION_ID

elm migration start --migration-id $MIGRATION_ID

这会启动回填和实时更新过程。 ELM 正在从源存储库收集数据，并且监听支持的 Webhook 事件。

6.监视迁移

迁移开始时，应会看到新的存储库。GHE.com 在迁移过程中，你将看到存储库填充了初始数据负载，并在开发人员继续在源存储库中工作时接收更新。

定期运行以下命令以监视迁移状态。你将看到源和目标的状态明细，以及有关要迁移的实时数据的信息。

Shell

elm migration status --migration-id $MIGRATION_ID

elm migration status --migration-id $MIGRATION_ID

响应中最重要的指示器是 combinedState 对象中的状态。当状态达到 COMBINED_STATUS_READY_FOR_CUTOVER时，应准备好继续执行下一步。但是，如果任何单个资源未能成功迁移，您可能需要对此进行调查，届时displayMessage中会发出警报。

例如：

  "combinedState":  {
    "status":  "COMBINED_STATUS_READY_FOR_CUTOVER",
    "displayMessage":  "Ready for cutover (1 resources failed)",
    "repositories":  [
      {
        "repositoryNwo":  "new-test-org/my-new-repo",
        "phase":  "REPOSITORY_PHASE_READY_FOR_CUTOVER",
        "displayStatus":  "Ready for cutover (1 failed)"
      }
    ],
    "readyForCutover":  true,
    "cutoverBlockers":  []
  },

提示：

如果运行的是多个迁移，则可以检查 elm migration list所有这些迁移的状态。此命令默认显示正在进行的迁移，但也可以按此 --status进行筛选。
如果遇到需要注意的失败状态，请参阅排查从 GitHub Enterprise Server 到 GHE.com 的实时迁移问题。

7. 完成迁移

当迁移准备好进行切换时，可以完成迁移。切换过程将锁定源存储库，让其永久不可用，除非管理员解锁它。

Shell

elm migration cutover-to-destination --migration-id $MIGRATION_ID

elm migration cutover-to-destination --migration-id $MIGRATION_ID

继续监视迁移。在响应顶部看到 MIGRATION_STATUS_COMPLETED 状态时，迁移已完成，但仍有一些后续任务需要执行，以便为 GitHub Enterprise Server 的用户提供访问权限。

后续步骤

向用户授予对新存储库的访问权限，并将活动与用户帐户进行协调。请参阅“完成从 GitHub Enterprise Server 到 GHE.com 的实时迁移”。

谁可以使用此功能？

在本文中

先决条件

1.创建访问令牌

2. 配置 GitHub Enterprise Server

3.设置所需的环境变量

4.创建迁移

保存迁移 ID

5.开始迁移

6.监视迁移

7. 完成迁移

后续步骤