Сведения о миграции организации с помощью GitHub Enterprise Importer
Миграции на GitHub Enterprise Cloud включают миграцию между учетными записями на GitHub.com и, если вы принимаете Место расположения данных, миграция в поддомен вашего предприятия GHE.com.
Необходимые компоненты
- Настоятельно рекомендуется выполнить пробную версию миграции и завершить рабочую миграцию в ближайшее время. Дополнительные сведения о пробных запусках см. в разделе Обзор миграции между продуктами GitHub.
- Убедитесь, что вы понимаете данные, которые будут перенесены, и известные ограничения поддержки импорта. Дополнительные сведения см. в разделе Сведения о миграции между продуктами GitHub.
- Хотя и не требуется, рекомендуется остановить работу во время рабочей миграции. Importer не поддерживает разностную миграцию, поэтому любые изменения, которые происходят во время миграции, не будут переноситься. Если вы решили не останавливать работу во время рабочей миграции, необходимо вручную перенести эти изменения.
- Для исходной организации необходимо быть владелец организации или иметь роль миграции. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.
- Для целевой корпоративной учетной записи необходимо быть владельцем предприятия.
Шаг 0. Подготовка к использованию API GraphQL GitHub
Чтобы сделать запросы GraphQL, вам потребуется написать собственные скрипты или использовать HTTP-клиент, такой как бессонница.
Дополнительные сведения о начале работы с API GraphQL GitHub GraphQL, включая проверку подлинности, см. в статье Формирование вызовов с помощью GraphQL.
Все запросы GraphQL отправляются в место назначения миграции. Если вы переносите данные GitHub Enterprise Cloud с размещением данных, обязательно отправьте запросы в конечную точку поддомена вашего предприятия GHE.com.
Шаг 1. Получение корпоративного идентификатора для назначения миграции
Как владелец предприятия в GitHub.com, используйте следующий запрос, чтобы вернуть идентификатор учетной записи предприятия, которую вы хотите владеть перенесенной организацией. Вам потребуется корпоративный идентификатор для идентификации назначения миграции.
query(
$slug: String!
){
enterprise (slug: $slug)
{
slug
id
}
}
Переменная запроса | Description |
---|---|
slug | Слизь для вашей корпоративной учетной записи, которую можно определить, просматривая URL-адрес вашей организации https:/ или https:/ . |
Шаг 2. Запуск миграции организации
При запуске миграции отдельная организация и ее сопровождающие данные переносятся в новую организацию в целевом предприятии, которое вы определяете.
mutation startOrganizationMigration (
$sourceOrgUrl: URI!,
$targetOrgName: String!,
$targetEnterpriseId: ID!,
$sourceAccessToken: String!,
$targetAccessToken: String!
){
startOrganizationMigration( input: {
sourceOrgUrl: $sourceOrgUrl,
targetOrgName: $targetOrgName,
targetEnterpriseId: $targetEnterpriseId,
sourceAccessToken: $sourceAccessToken,
targetAccessToken: $targetAccessToken
}) {
orgMigration {
id
}
}
}
Переменная запроса | Description |
---|---|
sourceOrgUrl | URL-адрес исходной организации, например https:/ . |
targetOrgName | Имя, которое будет иметь новая организация. Невозможно совместно использовать другую организацию на целевой платформе. |
target | Идентификатор предприятия, в который вы хотите создать новую организацию, возвращается на шаге 2. |
sourceAccessToken | Данные personal access token (classic) для исходной организации. Сведения о требованиях см. в разделе Управление доступом к миграции между продуктами GitHub. |
targetAccessToken | Данные personal access token (classic) для целевого предприятия. |
На следующем шаге вы будете использовать идентификатор миграции, возвращенный из startOrganizationMigration
изменения, чтобы проверить состояние миграции.
Шаг 3. Проверка состояния миграции
Чтобы обнаружить все сбои миграции и убедиться, что миграция работает, можно запросить OrganizationMigration
созданные (s) запросы, чтобы просмотреть состояние миграции с помощью getMigration
запроса.
Запрос возвращается с состоянием, чтобы сообщить, является queued
ли миграция , in progress``failed
или completed
, а также сведения о том, сколько репозиториев ожидает миграции. Если миграция завершилась сбоем, Importer предоставит причину сбоя.
query (
$id: ID!
){
node( id: $id ) {
... on OrganizationMigration {
id
sourceOrgUrl
targetOrgName
state
failure_reason
remaining_repositories_count
total_repositories_count
}
}
}
Переменная запроса | Description |
---|---|
id | Миграция id . |
После завершения миграции рекомендуется проверить репозиторий журналов миграции. Дополнительные сведения см. в разделе Доступ к журналам миграции для GitHub Enterprise Importer.
Наконец, мы рекомендуем выполнить проверку звука вашей организации и перенесенные репозитории.