Миграция вашего репозитория с помощью Enterprise Live Migrations

Необходимые условия

Убедитесь, что вы готовы к миграции. См . раздел AUTOTITLE.

1. Создание токенов доступа

Вы должны аутентифицироваться с помощью a personal access token (classic) как для источника, так и для назначения миграции. Подробные инструкции см. в разделе Управление личными маркерами доступа.

          **Запишите оба жетона**, так как они понадобятся вам на следующем этапе.

1. Создайте personal access token (classic) ON GitHub Enterprise Server с помощью следующих телескопов.

   • repo
   • admin:org
   • admin:repo_hook
   • admin:org_hook

2. Создайте personal access token (classic) ON GHE.com с помощью следующих телескопов.

   • repo
   • workflow
   • admin:org
   • admin:repo_hook
   • admin:enterprise

3. Если для целевой организации GHE.comGHE.com на , авторизуйте токен.

2. Настройте GitHub Enterprise Server

Перед миграцией необходимо установить некоторую конфигурацию GitHub Enterprise Server на экземпляре. Эти значения конфигурации применимы ко всем ELM миграциям. Разработчики GitHub Enterprise Server могут столкнуться с коротким простоем при применении новой конфигурации.

1. Доступ к GitHub Enterprise Server административной оболочке через SSH. См . раздел AUTOTITLE.

2. Установим следующие переменные конфигурации с ghe-config.

   Например: ghe-config app.elm-exporter.enabled true

   Variable	Настрой это на...
   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	URL API для вашего целевого предприятия (например: https://api.octocorp.ghe.com).

          **Не** указывайте слэш в конце URL. |
   

   | secrets.elm-exporter.migration-target-token | Токен доступа, который вы создали для GHE.com. | | secrets.elm-exporter.source-token | Токен доступа, который вы создали для GitHub Enterprise Server. | | secrets.elm-exporter.source-user | Имя пользователя, связанное с токеном GitHub Enterprise Server (например: ghe-admin). |

3. Если у вас ещё нет включённых миграций и хранилища blob на инстансе, вы можете настроить их сейчас. Вы можете проверить существующие настройки в разделе «Migrations» в Консоли управления (HOSTNAME/setup/settings).

   Вы можете использовать следующие значения по умолчанию, которые не введут никакой неожиданной функциональности.

   Shell

   ghe-config app.migrations.enabled true
   

   Shell

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

4. Примените конфигурацию.

   Shell

   ghe-config-apply
   

3. Задайте необходимые переменные среды

После применения конфигурации и перед началом миграции задайте необходимые переменные среды. Рассмотрим пример.

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

          **Не** указывайте слэш в конце URL. |

| MIGRATION_TARGET_TOKEN | Фор personal access token (classic)GHE.com |

Любое из этих значений также может быть предоставлено в виде CLI-флагов для любой elm команды, которая будет иметь приоритет над переменными. Например: --api-url http://localhost:1738.

4. Создать миграцию

Создайте новую миграцию, указав данные исходного и целевой репозиторий. --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 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 миграции.

elm migration start --migration-id $MIGRATION_ID

elm migration start --migration-id $MIGRATION_ID

Это запускает процессы заполнения и обновления в реальном времени. ELM Сейчас собирает данные из исходного репозитория и прослушивает поддерживаемые события Webhook.

6. Мониторинг миграции

Когда миграция начнётся, вы должны увидеть новый репозиторий на GHE.com. Во время миграции репозиторий заполняется первоначальной загрузкой данных и будет получать обновления по мере того, как разработчики продолжают работать в исходном репозитории.

Регулярно выполняйте следующую команду для мониторинга статуса миграции. Вы увидите разбивку статусов источника и цели, а также информацию о текущих данных, которые перемещаются.

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. Завершить миграцию

Когда миграция готова к переходу, вы сможете завершить её. Процесс перехода блокирует исходный репозиторий, делая его навсегда недоступным для разработчиков, если администратор не разблокирует его.

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

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

Продолжайте отслеживать миграцию. Когда вы видите MIGRATION_STATUS_COMPLETED статус в верхней части ответа, миграция завершена, хотя есть некоторые последующие задачи, предоставляющие пользователям доступ из GitHub Enterprise Server.

Дальнейшие действия

Дайте пользователям доступ к новому репозиторию и сверьте активность с учётными записями пользователей. См . раздел AUTOTITLE.