Экспорт данных миграции из GitHub.com

Подготовка исходной организации к GitHub

1. Убедитесь, что у вас есть разрешения владельца в репозиториях исходной организации.

2. Создание маркера доступа с областями repo и admin:org в GitHub.com.

3. Чтобы свести к минимуму время простоя, создайте список репозиториев, которые необходимо экспортировать из исходного экземпляра. Можно добавить сразу несколько репозиториев для экспорта с помощью текстового файла, в котором указаны URL-адреса каждого репозитория в отдельной строке.

Экспорт репозиториев организации

Чтобы экспортировать данные репозитория из GitHub.com, используйте API миграций.

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

Создание архива миграции

1. Уведомите членов вашей организации о том, что вы планируете выполнять миграцию. Экспорт может занять несколько минут в зависимости от количества экспортируемых репозиториев. Полная миграция, включая импорт, может занять несколько часов, поэтому рекомендуется выполнить пробный запуск, чтобы определить, сколько времени займет весь процесс. Дополнительные сведения см. в разделе Сведения о миграции ghe-миграции.

2. Запустите миграцию, отправив запрос POST к конечной точке миграции. Требуется:

   • Маркер доступа для проверки подлинности

   • Список репозиториев, которые требуется перенести:

     curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" \
     -X POST \
     -H "Accept: application/vnd.github+json" \
     -d'{"lock_repositories":true,"repositories":["ORG_NAME</em>/REPO_NAME", "ORG_NAME/REPO_NAME"]}' \
     https://api.github.com/orgs/ORG_NAME/migrations
     

   • Если вы хотите заблокировать репозитории перед их переносом, убедитесь, что для параметра lock_repositories задано значение true. Настоятельно рекомендуется сделать это.

   • Вы можете исключить вложения файлов, передав exclude_attachments: true в конечную точку. Вложения файлов могут быть большими и могут без необходимости увеличить размер окончательного архива миграции. Окончательный размер архива должен быть меньше 20 ГБ.

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

3. Отправьте запрос GET в конечную точку статуса миграции, чтобы получить статус миграции. Требуется:

   • Маркер доступа для проверки подлинности

   • Уникальный id миграции:

     curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" \
     -H "Accept: application/vnd.github+json" \
     https://api.github.com/orgs/ORG_NAME/migrations/ID
     

   Миграция может находиться в одном из указанных ниже состояний.

   • pending — это означает, что миграция еще не запущена.
   • exporting — это означает, что миграция находится в процессе выполнения.
   • exported — это означает, что миграция успешно завершена.
   • failed — это означает, что миграция завершилась сбоем.

4. После экспорта миграции скачайте архив миграции, отправив запрос GET к конечной точке загрузки миграции. Требуется:

   • Маркер доступа для проверки подлинности

   • Уникальный id миграции:

     curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" \
     -H "Accept: application/vnd.github+json" \
     -L -o migration_archive.tar.gz \
     https://api.github.com/orgs/ORG_NAME/migrations/ID/archive
     

5. Архив миграции автоматически удаляется через семь дней. Если вы предпочитаете удалить его раньше, можно отправить запрос DELETE в конечную точку удаления архива миграции. Требуется:

   • Маркер доступа для проверки подлинности

   • Уникальный id миграции:

     curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" \
     -X DELETE \
     -H "Accept: application/vnd.github+json" \
     https://api.github.com/orgs/ORG_NAME/migrations/ID/archive
     

6. Сведения о подготовке архивных данных миграции для импорта в экземпляр GitHub Enterprise Server см. в разделе "Перенос данных на GitHub Enterprise Server".