Сведения о миграции организации с помощью GitHub Enterprise Importer
Необходимые компоненты
- Настоятельно рекомендуется выполнить пробную версию миграции и завершить рабочую миграцию в ближайшее время. Дополнительные сведения о пробных запусках см. в разделе "Обзор миграции между продуктами GitHub".
- Убедитесь, что вы понимаете данные, которые будут перенесены, и известные ограничения поддержки импорта. Дополнительные сведения см. в разделе "Сведения о миграции между продуктами GitHub".
- Хотя и не требуется, рекомендуется остановить работу во время рабочей миграции. Importer не поддерживает разностную миграцию, поэтому любые изменения, которые происходят во время миграции, не будут переноситься. Если вы решили не останавливать работу во время рабочей миграции, необходимо вручную перенести эти изменения.
- Для исходной организации необходимо быть владелец организации или иметь роль миграции. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.
- Для целевой корпоративной учетной записи необходимо быть владельцем предприятия.
Шаг 0. Подготовка к использованию API GraphQL GitHub
Чтобы сделать запросы GraphQL, вам потребуется написать собственные скрипты или использовать HTTP-клиент, такой как бессонница.
Дополнительные сведения о начале работы с API GraphQL GitHub GraphQL, включая аутентификацию, см. в разделе "Формирование вызовов с помощью GraphQL".
Шаг 1. Получение корпоративного идентификатора для назначения миграции
Как владелец предприятия в GitHub.com, используйте следующий запрос, чтобы вернуть идентификатор учетной записи предприятия, которую вы хотите владеть перенесенной организацией. Вам потребуется корпоративный идентификатор для идентификации назначения миграции.
query(
$slug: String!
){
enterprise (slug: $slug)
{
slug
id
}
}
Переменная запроса | Description |
---|---|
slug | Slug для вашей корпоративной учетной записи, которую можно определить, просматривая URL-адрес для вашего предприятия, https://github.com/enterprises/SLUG . |
Шаг 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://github.com/octo-org . |
targetOrgName | Имя, которое будет иметь новая организация. Должен быть уникальным для GitHub.com. |
targetEnterpriseId | Идентификатор предприятия, в который вы хотите создать новую организацию, возвращается на шаге 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 . |
Шаг 1. Установка GEI extension of the GitHub CLI
Если это первая миграция, необходимо установить GEI extension of the GitHub CLI. Дополнительные сведения о GitHub CLIсм. в разделе "Сведения о GitHub CLI".
-
Установите GitHub CLI. Инструкции по установке для GitHub CLI см. в репозитории GitHub CLI.
Примечание. Вам нужна версия 2.4.0 или более позднюю версию GitHub CLI. Вы можете проверка версию, установленную
gh --version
с помощью команды. -
Установите GEI extension.
Shell gh extension install github/gh-gei
gh extension install github/gh-gei
В любое время, когда вам нужна помощь с GEI extension, можно использовать --help
флаг с помощью команды. Например, gh gei --help
перечислит все доступные команды и gh gei migrate-repo --help
отобразит список всех параметров, доступных для migrate-repo
команды.
Шаг 2. Обновление GEI extension of the GitHub CLI
Данные GEI extension обновляются еженедельно. Чтобы убедиться, что вы используете последнюю версию, обновите расширение.
gh extension upgrade github/gh-gei
Шаг 3. Задание переменных среды
Прежде чем использовать GEI extension для миграции на GitHub Enterprise Cloud, необходимо создать personal access tokens (classic), которые могут получить доступ к исходной организации и целевой организации, а затем задать personal access tokens (classic) в качестве переменных среды.
-
Создайте и запишите personal access token, которая соответствует всем требованиям для проверки подлинности исходной организации для миграции организации. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.
-
Создайте и запишите personal access token (classic), которая соответствует всем требованиям для проверки подлинности целевого предприятия для миграции организации.
-
Задайте переменные среды для personal access tokens (classic), заменив TOKEN в командах ниже personal access tokens (classic), записанных выше. Используется
GH_PAT
для целевого предприятия иGH_SOURCE_PAT
исходной организации.-
Если вы используете терминал, используйте
export
команду.Shell export GH_PAT="TOKEN" export GH_SOURCE_PAT="TOKEN"
export GH_PAT="TOKEN" export GH_SOURCE_PAT="TOKEN"
-
Если вы используете PowerShell, используйте
$env
команду.Shell $env:GH_PAT="TOKEN" $env:GH_SOURCE_PAT="TOKEN"
$env:GH_PAT="TOKEN" $env:GH_SOURCE_PAT="TOKEN"
-
Шаг 4. Перенос организации
Чтобы перенести организацию gh gei migrate-org
, используйте команду.
gh gei migrate-org --github-source-org SOURCE --github-target-org DESTINATION --github-target-enterprise ENTERPRISE
gh gei migrate-org --github-source-org SOURCE --github-target-org DESTINATION --github-target-enterprise ENTERPRISE
Замените заполнители в приведенной выше команде следующими значениями.
Заполнитель | Значение |
---|---|
ИСТОЧНИК | Имя исходной организации |
НАЗНАЧЕНИЕ | Имя, которое будет иметь новая организация. Должен быть уникальным для GitHub.com. |
ENTERPRISE | Слизь для целевого предприятия, который можно определить, просматривая URL-адрес вашей корпоративной учетной записи. https://github.com/enterprises/SLUG |
Шаг 5. Проверка миграции и проверка журнала ошибок
После завершения миграции рекомендуется проверить репозиторий журналов миграции. Дополнительные сведения см. в разделе Доступ к журналам миграции для GitHub Enterprise Importer.
Наконец, мы рекомендуем выполнить проверку звука вашей организации и перенесенные репозитории.