Перенос организаций из GitHub.com в GitHub Enterprise Cloud

Сведения о миграции организации с помощью GitHub Enterprise Importer

Чтобы просмотреть инструкции по использованию API, используйте переключатель инструментов в верхней части страницы.

Чтобы просмотреть инструкции по использованию GitHub CLI, используйте переключатель инструментов в верхней части страницы.

Необходимые компоненты

Настоятельно рекомендуется выполнить пробную версию миграции и завершить рабочую миграцию в ближайшее время. Дополнительные сведения о пробных запусках см. в разделе "Обзор миграции между продуктами 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 для исходной организации. Требования см. в разделе "Управление доступом к миграции между продуктами GitHub".
`targetAccessToken`	Данные personal access token для целевого предприятия.

На следующем шаге вы будете использовать идентификатор миграции, возвращенный из 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, которые могут получить доступ к исходной организации и целевой организации, а затем задать personal access tokens в качестве переменных среды.

Создайте и запишите personal access token, которая соответствует всем требованиям для проверки подлинности исходной организации для миграции организации. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.
Создайте и запишите personal access token, которая соответствует всем требованиям для проверки подлинности целевого предприятия для миграции организации.
Задайте переменные среды для personal access tokens, заменив TOKEN в командах ниже personal access tokens, записанных выше. Используется 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 , используйте команду.

Shell

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. Проверка миграции и проверка журнала ошибок

Шаг 4. Проверка миграции и проверка журнала ошибок

После завершения миграции рекомендуется проверить репозиторий журналов миграции. Дополнительные сведения см. в разделе Доступ к журналам миграции для GitHub Enterprise Importer.

Наконец, мы рекомендуем выполнить проверку звука вашей организации и перенесенные репозитории.