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

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

Миграции на GitHub Enterprise Cloud включают миграцию между учетными записями на GitHub.com и, если вы принимаете Место расположения данных, миграция в поддомен вашего предприятия GHE.com.

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

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

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

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

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

Настоятельно рекомендуется выполнить пробную версию миграции и завершить рабочую миграцию в ближайшее время. Дополнительные сведения о пробных запусках см. в разделе Обзор миграции между продуктами GitHub.
Убедитесь, что вы понимаете данные, которые будут перенесены, и известные ограничения поддержки импорта. Дополнительные сведения см. в разделе О миграциях между GitHub продуктами с GitHub Enterprise Importer.
Хотя и не требуется, рекомендуется остановить работу во время рабочей миграции. Importer не поддерживает разностную миграцию, поэтому любые изменения, которые происходят во время миграции, не будут переноситься. Если вы решили не останавливать работу во время рабочей миграции, необходимо вручную перенести эти изменения.
В исходной и целевой организации необходимо либо владелец организации, либо предоставить роль миграции. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.

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

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

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

Все запросы GraphQL отправляются в место назначения миграции. Если вы переносите данные GitHub Enterprise Cloud с размещением данных, обязательно отправьте запросы в конечную точку поддомена вашего предприятия GHE.com.

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

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

`GetOrgInfo` запрос

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

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

`GetOrgInfo` ответ

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

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

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

Вы можете настроить источник миграции с помощью createMigrationSource запроса. Вам потребуется указать ownerIdидентификатор организации, собранный GetOrgInfo из запроса.

Источник миграции — это организация на 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.

Переменная запроса	Description
`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
    }
  }
}

Переменная запроса	Description
`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.
`accessToken`	personal access token для источника.
`targetRepoVisibility`	Видимость нового репозитория. Должно быть `private`, `public` или `internal`. Если этот параметр не задан, репозиторий переносится как закрытый.
`sourceRepositoryUrl`	URL-адрес исходного репозитория с использованием формата `https://github.com/{organization}/{repository}`.

Требования к personal access token см. в разделе Управление доступом к миграции между продуктами GitHub.

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

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

Чтобы обнаружить любые сбои миграции и убедиться, что миграция работает, можно проверить состояние миграции с помощью getMigration запроса. Вы также можете проверить состояние нескольких миграций.getMigrations

Запрос getMigration возвращается с состоянием, чтобы сообщить, является queuedли миграция , in progress``failedили completed. Если миграция завершилась сбоем, Importer предоставит причину сбоя.

`getMigration` запрос

query (
  $id: ID!
){
  node( id: $id ) {
    ... on Migration {
      id
      sourceUrl
      migrationSource {
        name
      }
      state
      failureReason
    }
  }
}

Переменная запроса	Description
`id`	Миграция`id`, возвращаемая мутацией`startRepositoryMigration`.

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

Чтобы завершить миграцию, рекомендуется проверить проблему журнала миграции. Эта проблема создается на GitHub в целевом репозитории.

Снимок экрана: проблема с заголовком "Журнал миграции". Второй комментарий в этой проблеме включает журналы для миграции.

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

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

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

Кроме того, можно скачать автономный двоичный файл на странице выпусков для github/gh-gei репозитория. Двоичный файл можно запускать напрямую без gh префикса.

Установите 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 (classic), которая будет проходить проверку подлинности для целевой организации на GitHub Enterprise Cloud, убедившись, что маркер соответствует всем требованиям. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.
Создайте и запишите personal access token, которая будет проходить проверку подлинности для исходной организации, убедившись, что этот маркер также соответствует всем одинаковым требованиям.
Задайте переменные среды для personal access tokens, заменив TOKEN в командах ниже personal access token, записанных выше. Используется 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"
```
Если вы переходите на GitHub Enterprise Cloud с размещением данных, для удобства, установите переменную среды для базового URL API для вашего предприятия.

Убедитесь, что вы заменили SUBDOMAIN его на поддомен вашего предприятия. Например, если поддоменом вашего предприятия является acme, значением TARGET_API_URL будет .https://api.acme.ghe.com
- Если вы используете терминал, используйте export команду.
  Shell
```
export TARGET_API_URL="https://api.SUBDOMAIN.ghe.com"
```
```
export TARGET_API_URL="https://api.SUBDOMAIN.ghe.com"
```
- Если вы используете PowerShell, используйте $env команду.
  Shell
```
$env:TARGET_API_URL="https://api.SUBDOMAIN.ghe.com"
```
```
$env:TARGET_API_URL="https://api.SUBDOMAIN.ghe.com"
```
Вы используете эту переменную с --target-api-url опцией в командах, которые выполняете с GitHub CLI.

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

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

Примечание.

Создание скрипта выводит скрипт PowerShell. Если вы используете терминал, вам потребуется вывести сценарий с .ps1 расширением файла и установить PowerShell для Mac[ или Linux, ](https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-macos?view=powershell-7.2)чтобы запустить его.

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

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

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

Shell

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

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

Если вы скачали GEI как автономный двоичный файл, а не как расширение для GitHub CLI, необходимо обновить созданный скрипт, чтобы запустить двоичный файл вместо gh geiнего.

Заполнители

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

Заполнитель	Значение
ИСТОЧНИК	Имя исходной организации
НАЗНАЧЕНИЕ	Имя целевой организации
FILENAME	Имя файла для результирующего скрипта миграции Если вы используете терминал, используйте `.ps1` расширение файла в качестве созданного скрипта, чтобы запустить PowerShell. Вы можете установить PowerShell для Mac или Linux.

Дополнительные аргументы

Аргумент	Description
`--target-api-url TARGET-API-URL`	Если вы переносите данные GHE.com, добавьте `--target-api-url TARGET-API-URL`, где TARGET-API-URL является базовым URL-адресом API для поддомена предприятия. Например: `https://api.octocorp.ghe.com`.
`--download-migration-logs`	Скачайте журнал миграции для каждого перенесенного репозитория. Дополнительные сведения о журналах миграции см. в разделе Доступ к журналам миграции для GitHub Enterprise Importer.

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

После создания скрипта просмотрите файл и, при необходимости, измените скрипт.

Если есть какие-либо репозитории, которые вы не хотите перенести, удалить или закомментировать соответствующие строки.
Если в целевой организации есть другое имя репозиториев, обновите значение соответствующего --target-repo флага.
Если вы хотите изменить видимость нового репозитория, обновите значение соответствующего --target-repo-visibility флага. По умолчанию скрипт задает ту же видимость, что и исходный репозиторий.

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

Шаг 5. Миграция репозиториев

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

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

Чтобы мигрировать несколько репозиториев, запустите сгенерированный вами скрипт. Замените FILENAME в приведенных ниже командах именем файла, указанным при создании скрипта.

Если вы используете терминал, используйте ./.
Shell
```
./FILENAME
```
```
./FILENAME
```
Если вы используете PowerShell, используйте .\.
Shell
```
.\FILENAME
```
```
.\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

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

Заполнители

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

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

Дополнительные аргументы

Аргумент	Description
`--target-api-url TARGET-API-URL`	Если вы переносите данные GHE.com, добавьте `--target-api-url TARGET-API-URL`, где TARGET-API-URL является базовым URL-адресом API для поддомена предприятия. Например: `https://api.octocorp.ghe.com`.
`--skip-releases`	Если в репозитории имеется более 10 ГБ данных о выпусках, выпуски не могут быть перенесены. `--skip-releases` Используйте флаг для переноса репозитория без выпусков.
`--target-repo-visibility TARGET-VISIBILITY`	Репозитории переносятся с частной видимостью по умолчанию. Чтобы задать видимость, можно добавить флаг, указать `--target-repo-visibility` private``publicили .`internal` Если вы переносите данные корпоративный с управляемыми пользователями, общедоступные репозитории недоступны.

Прерывание миграции

Если вы хотите отменить миграцию, используйте abort-migration команду, заменив идентификатор MIGRATION-ID возвращенным идентификатором migrate-repo.

Shell

gh gei abort-migration --migration-id MIGRATION-ID

gh gei abort-migration --migration-id MIGRATION-ID

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

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

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

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

Tool navigation

В этой статье

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

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

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

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

`GetOrgInfo` запрос

`GetOrgInfo` ответ

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

`createMigrationSource` мутация

`createMigrationSource` ответ

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

`startRepositoryMigration` мутация

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

`getMigration` запрос

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

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

Шаг 2. Обновление GEI extension of the GitHub CLI

Шаг 3. Задание переменных среды

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

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

Заполнители

Дополнительные аргументы

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

Шаг 5. Миграция репозиториев

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

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

Заполнители

Дополнительные аргументы

Прерывание миграции

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