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

Совет

Следуя этому руководству, вы можете ознакомиться с Справочник CLI Enterprise Live Migrations для получения более подробной информации об использовании. Если вы столкнётесь с ошибками, смотрите Устранение неполадок при миграции в реальном времени с GitHub Enterprise Server на GHE.com.

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

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

1. Настройка GitHub Enterprise Server

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

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

Установим следующие переменные конфигурации с 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.source-user | Имя пользователя, связанное с маркером оператора GitHub Enterprise Server . Это должно быть ваше имя пользователя GitHub Enterprise Server; если кто-то другой собирается создать этот токен, значение здесь должно быть задано в качестве имени пользователя. Мы рекомендуем ghe-admin пользователю. |

Примените конфигурацию.
Shell
```
ghe-config-apply
```
```
ghe-config-apply
```
Оставьте сеанс SSH. Остальные команды будут выполняться в локальном сеансе терминала.

2. Создание маркеров оператора с корпоративным доступом

Оператор должен пройти проверку подлинности как в исходном, так и в целевом personal access token (classic)предприятии. Инструкции по созданию маркеров см. в разделе Управление личными маркерами доступа.

Убедитесь, что вы заметите оба маркера, так как они потребуются на следующем шаге.

В GitHub Enterprise Server поле "Создать personal access token (classic) " и выбрать требуемую область:
- admin:enterprise
Этот маркер будет использоваться в качестве исходного маркера при настройке ELM CLI.
В GHE.com поле "Создать personal access token (classic) " и выбрать необходимые области:
- admin:enterprise
- admin:org
Этот маркер будет использоваться в качестве целевого маркера при настройке ELM CLI.

3. Настройка средства командной ELM строки

Вы будете запускать миграцию из локального сеанса GitHub CLIтерминала, используя расширение .

Установите на локальном GitHub CLI компьютере. Необходимо использовать версию 2.0 или более позднюю.

Установите расширение ELM.

Shell

gh extension install github/gh-elm

gh extension install github/gh-elm

Запустите мастер установки, чтобы настроить расширение.
Shell
```
gh elm configure
```
```
gh elm configure
```
Следуйте инструкциям мастера установки, указав URL-адреса API (например, https://api.SUBDOMAIN.ghe.comдля источника и назначения) и маркеры, созданные на предыдущем шаге.

Любое из этих значений также можно указать как флаги CLI для любой gh elm команды, которая будет иметь приоритет над конфигурацией. Например: --target-url https://api.SUBDOMAIN.ghe.com.

Этот процесс установки будет хранить URL-адреса в файле конфигурации для конкретной платформы в каталоге конфигурации операционной системы.gh-elm/config.json Маркеры доступа будут безопасно храниться в хранилище секретов компьютера.

4. Настройка секретов динамической миграции

Помимо маркеров оператора с корпоративным доступом, необходимо создать personal access token (classic) для исходных и целевых организаций. Эти действия необходимо повторить для каждой организации, из которых выполняется миграция.

Создание маркеров доступа

ELM должен пройти проверку подлинности как 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 токен для единого входа.

Настройка секретов организации ELM

Используйте команды, чтобы задать исходные и целевые gh elm config маркеры доступа:

Задайте исходный маркер.
Shell
```
gh elm config set-source-pat EXISTING-GHES-ORG
```
```
gh elm config set-source-pat EXISTING-GHES-ORG
```
Вставьте исходный маркер в терминал при появлении запроса.
Задайте целевой маркер.
Shell
```
gh elm config set-target-pat EXISTING-GHES-ORG
```
```
gh elm config set-target-pat EXISTING-GHES-ORG
```
При появлении запроса вставьте целевой маркер в терминал.

Вы также можете задать маркеры в интерактивном режиме, с помощью gh elm config org-tokens EXISTING-GHES-ORGили в параметрах https://GHES_HOSTNAME/organizations/EXISTING-GHES-ORG/settings/secrets/elm-exporter/организации.

5. Создание миграции

Создайте новую миграцию, указав данные исходного и целевой репозиторий.

Примечание.

Они target-org могут быть новыми или уже существующими. Если целевая организация ещё не существует, она будет создана во время миграции. Однако настройки из исходной организации не будут мигрированы.

Shell

gh elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO

gh elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO

Рассмотрим пример.

gh elm migration create \
  --source-org my-ghes-org \
  --source-repo my-ghes-repo \
  --target-org my-dr-org \
  --target-repo my-dr-repo

Опциональные флаги:

--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'

6. Запуск миграции

Если вы ещё не начали миграцию, начните сейчас, используя только что сохранённый ID миграции.

Shell

gh elm migration start --migration-id $MIGRATION_ID

gh elm migration start --migration-id $MIGRATION_ID

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

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

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

Ход выполнения миграции можно отслеживать в интерактивном режиме watch с помощью команды:

gh elm migration watch $MIGRATION_ID

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

Программный мониторинг с помощью `migration status`

Если требуется состояние миграции, подходящее для автоматизации, используйте status команду:

Shell

gh elm migration status --migration-id $MIGRATION_ID

gh 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":  []
  },

Советы

Если вы запускаете несколько миграций, вы можете проверить статус всех с помощью gh elm migration list. Эта команда по умолчанию показывает миграции в процессе, но вы также можете фильтровать по --status.
Если вы столкнулись с статусами неудач, требующим внимания, смотрите Устранение неполадок при миграции в реальном времени с GitHub Enterprise Server на GHE.com.

8. Завершение миграции

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

Shell

gh elm migration cutover --migration-id $MIGRATION_ID

gh elm migration cutover --migration-id $MIGRATION_ID

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

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

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

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

Кто может использовать эту функцию?

В этой статье

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

1. Настройка GitHub Enterprise Server

2. Создание маркеров оператора с корпоративным доступом

3. Настройка средства командной ELM строки

4. Настройка секретов динамической миграции

Создание маркеров доступа

Настройка секретов организации ELM

5. Создание миграции

Сохранить ID миграции

6. Запуск миграции

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

Программный мониторинг с помощью `migration status`

8. Завершение миграции

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

Была ли эта документация полезной?

По-прежнему нужна помощь?