Перенос репозиториев из GitHub.com в GitHub Enterprise Cloud

Примечание. GitHub Enterprise Importer в настоящее время находится в общедоступной бета-версии и может быть изменен.

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

Миграцию можно выполнить с помощью GitHub CLI или API.

GitHub CLI упрощает процесс миграции и рекомендуется для большинства клиентов. Опытные клиенты с большими потребностями в настройке могут использовать API для создания собственных интеграций с GitHub Enterprise Importer.

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

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

Предварительные требования

Чтобы убедиться, что вы понимаете известные ограничения поддержки средства импорта, ознакомьтесь с разделом Сведения о GitHub Enterprise Importer.
Мы настоятельно рекомендуем выполнить пробную версию миграции и завершить миграцию в рабочей среде вскоре после этого. Дополнительные сведения о рекомендациях по запуску пробной версии см. в разделе Подготовка к выполнению миграции с помощью GitHub Enterprise Importer.
Хотя это не обязательно, рекомендуется остановить работу во время миграции рабочей среды. Importer не поддерживает разностные миграции, поэтому любые изменения, происходящие во время миграции, не будут перенесены. Если вы решили не останавливать работу во время миграции рабочей среды, необходимо вручную перенести эти изменения.
Вы должны быть либо владелец организации, либо ему должна быть предоставлена роль миграции для исходной и целевой организаций. Дополнительные сведения см. в разделе Granting the migrator role for GitHub Enterprise Importer.

Шаг 0. Подготовка к использованию API GraphQL GitHub

Чтобы создавать запросы GraphQL, необходимо написать собственные скрипты или использовать HTTP-клиент, например Insomnia.

Дополнительные сведения о начале работы с API GraphQL GitHub, в том числе о проверке подлинности, см. в разделе Формирование вызовов с помощью GraphQL.

Шаг 1. Получение `ownerId` для назначения миграции

Как владелец организации в GitHub Enterprise Cloud используйте GetOrgInfo запрос, чтобы вернуть ownerIdидентификатор организации, которую вы хотите владеть перенесенными репозиториями. Вам потребуется , ownerId чтобы определить назначение миграции.

`GetOrgInfo` Запроса

query(
  $login: String!
){
  organization (login: $login)
  {
    login
    id
    name
    databaseId
  }
}

Переменная запроса	Описание
`login`	Название вашей организации.

`GetOrgInfo` Ответ

{
  "data": {
    "organization": {
      "login": "Octo",
      "id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
      "name": "Octo-org",
      "databaseId": 5610
    }
  }
}

В этом примере MDEyOk9yZ2FuaXphdGlvbjU2MTA= — это идентификатор организации или ownerId, который мы будем использовать на следующем шаге.

Шаг 2. Определение места миграции

You can set up a migration source using the createMigrationSource query. You'll need to supply the ownerId, or organization ID, gathered from the GetOrgInfo query.

Источником миграции является организация на GitHub.com.

`createMigrationSource` Мутации

mutation createMigrationSource($name: String!, $ownerId: ID!) {
  createMigrationSource(input: {name: $name, url: "https://github.com", ownerId: $ownerId, type: GITHUB_ARCHIVE}) {
    migrationSource {
      id
      name
      url
      type
    }
  }
}

Примечание: Обязательно используйте GITHUB_ARCHIVE для type.

Переменная запроса	Описание
`name`	Имя источника миграции. Это имя предназначено для вашей собственной ссылки, поэтому вы можете использовать любую строку.
`ownerId`	Идентификатор организации в GitHub Enterprise Cloud.

`createMigrationSource` Ответ

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
        "name": "GitHub.com Source",
        "url": "https://github.com",
        "type": "GITHUB_SOURCE"
      }
    }
  }
}

В этом примере MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA — это идентификатор источника миграции, который мы будем использовать на следующем шаге.

Шаг 3. Запуск миграции репозитория

При запуске миграции один репозиторий и сопровождающие его данные переносятся в новый репозиторий GitHub, который вы идентифицируете.

Если вы хотите переместить сразу несколько репозиториев из одной исходной организации, можно поместить несколько миграций в очередь. Одновременно можно выполнить до 5 миграций репозитория.

`startRepositoryMigration` Мутации

mutation startRepositoryMigration (
  $sourceId: ID!,
  $ownerId: ID!,
  $sourceRepositoryUrl: URI!,
  $repositoryName: String!,
  $continueOnError: Boolean!,
  $accessToken: String!,
  $githubPat: String!,
  $targetRepoVisibility: String!
){
  startRepositoryMigration( input: {
    sourceId: $sourceId,
    ownerId: $ownerId,
    repositoryName: $repositoryName,
    continueOnError: $continueOnError,
    accessToken: $accessToken,
    githubPat: $githubPat,
    targetRepoVisibility: $targetRepoVisibility
    sourceRepositoryUrl: $sourceRepositoryUrl,
  }) {
    repositoryMigration {
      id
      migrationSource {
        id
        name
        type
      }
      sourceUrl
    }
  }
}

Переменная запроса	Описание
`sourceId`	Источник `id` миграции вернулся из `createMigrationSource` изменения.
`ownerId`	Идентификатор организации в GitHub Enterprise Cloud.
`repositoryName`	Пользовательское уникальное имя репозитория, которое в настоящее время не используется ни в одном из репозиториев, принадлежащих организации в GitHub Enterprise Cloud. После завершения или остановки миграции в этом репозитории будет создана проблема с ведением журнала ошибок.
`continueOnError`	Параметр миграции, позволяющий продолжить миграцию при возникновении ошибок, которые не приводят к сбою миграции. Значение должно быть равно `true` или `false`. Мы настоятельно рекомендуем задать значение `continueOnError` , `true` чтобы миграция продолжалась, если Importer не может переместить источник Git или Importer не потерял подключение и не сможет повторно подключиться для завершения миграции.
`githubPat`	personal access token для целевой организации в GitHub Enterprise Cloud. Требования к personal access token см. в разделе Управление доступом для GitHub Enterprise Importer.
`accessToken`	personal access token для источника.
`targetRepoVisibility`	Видимость нового репозитория. Должно быть `private`, `public` или `internal`. Если этот параметр не задан, репозиторий переносится как частный.

Шаг 4. Проверка состояния миграции

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

To finish your migration, we recommend that you check the "Migration Log" issue. This issue is created on GitHub in the destination repository.

Screenshot of an issue with the title "Migration Log." The second comment in the issue includes logs for a migration.

Finally, we recommend that you review your migrated repositories for a soundness check.

Шаг 1. Установка GEI extension of the GitHub CLI

Если это ваша первая миграция, необходимо установить GEI extension of the GitHub CLI. Дополнительные сведения о GitHub CLI см. в разделе Сведения о GitHub CLI.

Install the GitHub CLI. Инструкции по установке для GitHub CLI см. в репозитории GitHub CLI.

Note: You need version 2.4.0 or newer of GitHub CLI. You can check the version you have installed with the gh --version command.

1. Установите GEI extension.
Shell
```
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 Enterprise Cloud, убедившись, что маркер соответствует всем требованиям. Дополнительные сведения см. в разделе Управление доступом для GitHub Enterprise Importer.
Создайте и запишите personal access token, который будет проходить проверку подлинности для исходной организации, убедившись, что этот маркер также соответствует всем требованиям. 1. Задайте переменные среды для personal access tokens, заменив TOKEN в приведенных ниже командах на personal access token, записанными ранее. Используйте GH_PAT для целевой организации и GH_SOURCE_PAT для исходной организации.
- Если вы используете терминал, используйте export команду .
  Shell
```
export GH_PAT="TOKEN"
export GH_SOURCE_PAT="TOKEN"
```
- Если вы используете PowerShell, используйте $env команду .
  Shell
```
$env:GH_PAT="TOKEN"
$env:GH_SOURCE_PAT="TOKEN"
```

Шаг 4. Создание скрипта миграции

Если вы хотите перенести несколько репозиториев в GitHub Enterprise Cloud одновременно, используйте GitHub CLI для создания скрипта миграции. Результирующий скрипт будет содержать список команд миграции, по одной для каждого репозитория.

Примечание: При создании скрипта выводится скрипт PowerShell. Если вы используете терминал, необходимо вывести скрипт с расширением .ps1 файла и установить PowerShell для Mac или Linux , чтобы запустить его.

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

Создание скрипта миграции

Чтобы создать скрипт миграции, выполните gh gei generate-script команду .

Shell

gh gei generate-script --github-source-org SOURCE --github-target-org DESTINATION --output FILENAME

If you want the script to download the migration log for each migrated repository, add the --download-migration-logs flag. For more information about migration logs, see "Доступ к журналам миграции для GitHub Enterprise Importer."

Замените заполнители в приведенной выше команде следующими значениями.

Заполнитель | Значение | ----------- | ----- | ИСТОЧНИК | Имя исходной организации НАЗНАЧЕНИЕ | Имя целевой организации FILENAME | Имя файла для результирующего скрипта миграции

Если вы используете терминал, используйте .ps1 расширение файла, так как для запуска созданного скрипта требуется PowerShell. Вы можете установить PowerShell для Mac или Linux.

Просмотр скрипта миграции

After you generate the script, review the file and, optionally, edit the script.

If there are any repositories you don't want to migrate, delete or comment out the corresponding lines.
If you want any repositories to have a different name in the destination organization, update the value for the corresponding --target-repo flag.

Примечание: Если в репозитории содержится более 10 ГБ данных о выпусках, выпуски нельзя перенести. Используйте флаг для --skip-releases переноса репозитория без выпусков.

Шаг 5. Перенос репозиториев

Вы можете перенести несколько репозиториев с помощью скрипта миграции или один репозиторий gh gei migrate-repo с помощью команды .

Перенос нескольких репозиториев

To migrate multiple repositories, run the script you generated above. Replace FILENAME in the commands below with the filename you provided when generating the script.

If you're using Terminal, use ./.
Shell
```
./FILENAME
```
If you're using PowerShell, use .\.
Shell
```
.\FILENAME
```

Перенос одного репозитория

Чтобы перенести один репозиторий, используйте gh gei migrate-repo команду .

Shell

gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME

Примечание: Если в репозитории содержится более 10 ГБ данных о выпусках, выпуски нельзя перенести. Используйте флаг для --skip-releases переноса репозитория без выпусков.

Замените заполнители в приведенной выше команде следующими значениями.

Заполнитель	Значение
ИСТОЧНИК	Имя исходной организации
CURRENT-NAME	Имя репозитория, который требуется перенести.
НАЗНАЧЕНИЕ	Имя целевой организации
NEW-NAME	Имя перенесенного репозитория

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

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

Мы рекомендуем проверить перенесенные репозитории для проверки правильности.

Перенос репозиториев из GitHub.com в GitHub Enterprise Cloud

В этой статье