Skip to main content
Мы публикуем частые обновления нашей документации, и перевод этой страницы может все еще выполняться. Актуальные сведения см. в документации на английском языке.
All products
Миграции

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

В этой статье

Вы можете перенести репозитории из GitHub Enterprise Server в GitHub Enterprise Cloud с помощью GitHub CLI или API.

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

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

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

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

Если вы решите использовать API, вам потребуется написать собственные скрипты или использовать HTTP-клиент, например Insomnia. Дополнительные сведения о начале работы с APIGitHubсм. в разделе Начало работы с REST API и Формирование вызовов с помощью GraphQL.

Чтобы перенести репозитории из GitHub Enterprise Server в GitHub Enterprise Cloud с помощью API, выполните следующие действия:

  1. Создание personal access token для исходной и целевой организации
  2. Получение целевой ownerId организации на GitHub Enterprise Cloud
  3. Настройка источника миграции с помощью API GraphQL GitHub.com, чтобы определить, откуда выполняется миграция.
  4. Для каждого репозитория, который требуется перенести, повторите эти действия.
    • Создание архивов миграции для репозитория с помощью REST API в экземпляр GitHub Enterprise Server
    • Отправьте архивы миграции в расположение, где к им может получить доступ GitHub.com
    • Начните миграцию с помощью API GraphQL для GitHub.com, передав URL-адреса архива
    • Проверка состояния миграции с помощью API GraphQL
    • Проверка миграции и проверка журнал ошибок

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

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

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

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

Шаг 1. Создание personal access token

  1. Создайте и запишите personal access token (classic), который будет проходить проверку подлинности для целевой организации на GitHub Enterprise Cloud, убедившись, что маркер соответствует всем требованиям. Дополнительные сведения см. в разделе Управление доступом для GitHub Enterprise Importer.
  2. Создайте и запишите personal access token, который будет проходить проверку подлинности для исходной организации, убедившись, что этот маркер также соответствует всем требованиям.

Шаг 2. Получение 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, который мы будем использовать на следующем шаге.

Шаг 3. Настройка хранилища BLOB-объектов

Так как многие экземпляры GitHub Enterprise Server располагаются за брандмауэрами, для GitHub Enterprise Server версии 3.8 или более поздней мы используем хранилище BLOB-объектов в качестве промежуточного расположения для хранения данных, к которым может получить доступ GitHub.

Сначала необходимо настроить хранилище BLOB-объектов у поддерживаемого поставщика облачных служб, а затем настроить параметры в Консоль управления экземпляр GitHub Enterprise Server.

Примечание. Настроить хранилище BLOB-объектов нужно только при использовании GitHub Enterprise Server версии 3.8 или более поздней. Если вы используете GitHub Enterprise Server версии 3.7 или более поздней, перейдите к разделу Шаг 4. Настройка источника миграции в GitHub Enterprise Cloud.

Хранилище BLOB-объектов требуется для переноса репозиториев с большим источником или метаданными Git. Если вы используете GitHub Enterprise Server версии 3.7 или более поздней, вы не сможете выполнять миграцию, если объем экспорта исходных данных или метаданных Git превышает 2 ГБ. Чтобы выполнить эти миграции, обновите GitHub Enterprise Server версии 3.8 или более поздней.

Настройка хранилища BLOB-объектов с помощью поддерживаемого поставщика облачных служб

GitHub CLI поддерживает следующие поставщики хранилища BLOB-объектов:

  • Amazon Web Services (AWS) S3
  • хранилище BLOB-объектов Azure

Настройка контейнера хранилища AWS S3

In AWS, set up a S3 bucket. For more information, see Creating a bucket in the AWS documentation.

You will also need an AWS access key and secret key with read-write access to your bucket.

Note: GitHub Enterprise Importer does not delete your archive from AWS after your migration is finished. To reduce storage costs, we recommend configuring auto-deletion of your archive after a period of time. For more information, see Setting lifecycle configuration on a bucket in the AWS documentation.

Настройка учетной записи Хранилище BLOB-объектов Azure

В Azure создайте учетную запись хранения и запишите строку подключения. Дополнительные сведения см. в статье Управление ключами доступа к учетной записи хранения в Документация Майкрософт.

Примечание. GitHub Enterprise Importer не удаляет архив из Хранилище BLOB-объектов Azure после завершения миграции. Чтобы снизить затраты на хранение, рекомендуется настроить автоматическое удаление архива через некоторое время. Дополнительные сведения см. в статье Оптимизация затрат путем автоматического управления жизненным циклом данных в Документация Майкрософт.

Настройка хранилища BLOB-объектов в Консоль управления экземпляр GitHub Enterprise Server

После настройки контейнера хранилища AWS S3 или учетной записи хранения Хранилище BLOB-объектов Azure настройте хранилище BLOB-объектов в Консоль управления экземпляр GitHub Enterprise Server. Дополнительные сведения о Консоль управления см. в разделе Администрирование экземпляра из консоли управления.

  1. В учетной записи администратора GitHub Enterprise Cloud в правом верхнем углу любой страницы щелкните .
  2. Если вы еще не на странице "Администратор сайта", в левом верхнем углу щелкните Администратор сайта. 1. На боковой панели Администратор сайта щелкните Консоль управления.
  3. Войдите в Консоль управления.
  4. На верхней панели навигации щелкните Параметры.
  5. В разделе Миграции щелкните Включить миграции GitHub.
  6. При необходимости, чтобы импортировать параметры хранилища, настроенные для GitHub Actions, выберите Копировать параметры хранилища в разделе Действия. Дополнительные сведения см. в разделах Включение GitHub Actions с хранилищем BLOB-объектов Azure и Включение GitHub Actions с помощью хранилища Amazon S3.
  7. Если вы не импортируете параметры хранилища из GitHub Actions, выберите Хранилище BLOB-объектов Azure или Amazon S3 и укажите необходимые сведения.
  8. Щелкните Проверить параметры хранилища.
  9. Нажмите кнопку Сохранить параметры.

Шаг 4. Настройка источника миграции в GitHub Enterprise Cloud

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 Enterprise Server.

createMigrationSource Мутации

mutation createMigrationSource($name: String!, $url: String!, $ownerId: ID!) {
  createMigrationSource(input: {name: $name, url: $url, ownerId: $ownerId, type: GITHUB_ARCHIVE}) {
    migrationSource {
      id
      name
      url
      type
    }
  }
}

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

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

createMigrationSource Ответ

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ",
        "name": "GHES Source",
        "url": "https://my-ghes-hostname.com",
        "type": "GITHUB_ARCHIVE"
      }
    }
  }
}

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

Шаг 5. Создание архивов миграции в экземпляр GitHub Enterprise Server

REST API используется для запуска двух "миграций" в GitHub Enterprise Server: один для создания архива источника Git репозитория, а второй для создания архива метаданных репозитория (например, проблем и запросов на вытягивание).

Чтобы создать исходный POST архив Git, отправьте запрос к https://HOSTNAME/api/v3/orgs/ORGANIZATION/migrations, заменив HOSTNAME именем узла экземпляр GitHub Enterprise Server, а ORGANIZATION именем входа вашей организации.

В тексте укажите один репозиторий, который требуется перенести. Ваш запрос будет выглядеть примерно так:

POST /api/v3/orgs/acme-corp/migrations HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Content-Type: application/json
Host: github.acmecorp.net

{
  "repositories": ["repository_to_migrate"],
  "exclude_metadata": true
}

Чтобы создать архив метаданных, отправьте аналогичный запрос по тому же URL-адресу со следующим текстом:

{
  "repositories": ["repository_to_migrate"],
  "exclude_git_data": true,
  "exclude_releases": false,
  "exclude_owner_projects": true
}

Каждый из этих двух вызовов API возвращает ответ JSON с идентификатором начатой миграции.

HTTP/1.1 201 Created

{
  "id": 123,
  // ...
}

Дополнительные сведения см. в разделе "Запуск миграции организации" документации по REST API.

Создание архивов может занять некоторое время в зависимости от объема данных. Вы можете регулярно проверка состояние двух миграций с помощью API "Получение состояния миграции организации" до тех пор, пока значение миграции не state изменится на exported.

GET /api/v3/orgs/acme-corp/migrations/123 HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Host: github.acmecorp.net

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "state": "exported",
  // ...
}

Дополнительные сведения см. в разделе Получение состояния миграции организации в документации по REST API.

Примечание: Если миграция переходит в failed состояние , а не в exported состояние , попробуйте начать миграцию еще раз. Если миграция несколько раз завершается сбоем, рекомендуется создавать архивы с помощью ghe-migrator вместо API.

Выполните действия, описанные в разделе "Экспорт данных миграции из предприятия", добавив в миграцию только один репозиторий. В конце процесса у вас будет один архив миграции с источником и метаданными Git, и вы можете перейти к шагу 6 в этой статье.

state После перемещения миграции в exportedможно получить URL-адрес миграции с помощью API "Скачать архив миграции организации".

GET /api/v3/orgs/acme-corp/migrations/123/archive HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Host: github.acmecorp.net

HTTP/1.1 302 Found
Location: https://media.github.acmecorp.net/migrations/123/archive/cca2ebe9-7403-4ffa-9b6a-4c9e16c94410?token=AAAAABEWE7JP4H2HACKEGMTDOYRC6

API вернет 302 Found ответ с заголовком Location , перенаправляющимся на URL-адрес, по которому находится скачиваемый архив. Скачайте два файла: один для источника Git и один для метаданных.

Дополнительные сведения см. в разделе Скачивание архива миграции организации в документации по REST API.

После завершения обеих миграций и загрузки архивов можно перейти к следующему шагу.

Шаг 6. Отправка архивов миграции

Чтобы импортировать данные в GitHub Enterprise Cloud, необходимо передать оба архива для каждого репозитория (источника Git и метаданные) с компьютера в GitHub.com с помощью нашего API GraphQL.

Если вы используете GitHub Enterprise Server 3.7 или более поздней версии, необходимо сначала создать URL-адреса для архивов, доступных GitHub.com. Большинство клиентов предпочитают отправлять архивы в службу хранилища BLOB-объектов поставщика облачных служб, например Amazon S3 или Хранилище BLOB-объектов Azure, а затем создавать для каждого из них короткий URL-адрес.

Если вы используете GitHub Enterprise Server 3.8 или более поздней версии, экземпляр отправляет архивы и создает URL-адреса. Заголовок Location на предыдущем шаге вернет кратковременный URL-адрес.

Возможно, потребуется включить . Дополнительные сведения см. в разделе Управление доступом для GitHub Enterprise Importer.

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

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

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

startRepositoryMigration Мутации

mutation startRepositoryMigration (
  $sourceId: ID!,
  $ownerId: ID!,
  $repositoryName: String!,
  $continueOnError: Boolean!,
  $accessToken: String!,
  $githubPat: String!,
  $gitArchiveUrl: String!,
  $metadataArchiveUrl: String!,
  $sourceRepositoryUrl: URI!,
  $targetRepoVisibility: String!
){
  startRepositoryMigration( input: {
    sourceId: $sourceId,
    ownerId: $ownerId,
    repositoryName: $repositoryName,
    continueOnError: $continueOnError,
    accessToken: $accessToken,
    githubPat: $githubPat,
    targetRepoVisibility: $targetRepoVisibility
    gitArchiveUrl: $gitArchiveUrl,
    metadataArchiveUrl: $metadataArchiveUrl,
    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 не потерял подключение и не сможет повторно подключиться для завершения миграции.
githubPatpersonal access token для целевой организации в GitHub Enterprise Cloud. Требования к personal access token см. в разделе Управление доступом для GitHub Enterprise Importer.
accessTokenpersonal access token для источника.
targetRepoVisibilityВидимость нового репозитория. Должно быть private, public или internal. Если этот параметр не задан, репозиторий переносится как частный. gitArchiveUrl
metadataArchiveUrlURL-адрес, доступный для GitHub Enterprise Cloud, для архива метаданных.
sourceRepositoryUrlURL-адрес репозитория в экземпляре GitHub Enterprise Server. Это необходимо, но GitHub Enterprise Cloud не будет напрямую взаимодействовать с экземпляром GitHub Enterprise Server.

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

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

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.

  1. 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 в качестве переменных среды.

  1. Создайте и запишите personal access token (classic), который будет проходить проверку подлинности для целевой организации на GitHub Enterprise Cloud, убедившись, что маркер соответствует всем требованиям. Дополнительные сведения см. в разделе Управление доступом для GitHub Enterprise Importer.

  2. Создайте и запишите 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. Настройка хранилища BLOB-объектов

Так как многие экземпляры GitHub Enterprise Server располагаются за брандмауэрами, мы используем хранилище BLOB-объектов в качестве промежуточного расположения для хранения данных, к которым может получить доступ GitHub.

Во-первых, необходимо настроить хранилище BLOB-объектов с помощью поддерживаемого поставщика облачных служб. Затем необходимо настроить учетные данные для поставщика хранилища в Консоль управления или GitHub CLI.

Настройка хранилища BLOB-объектов с помощью поддерживаемого поставщика облачных служб

GitHub CLI поддерживает следующие поставщики хранилища BLOB-объектов:

  • Amazon Web Services (AWS) S3
  • хранилище BLOB-объектов Azure

Настройка контейнера хранилища AWS S3

In AWS, set up a S3 bucket. For more information, see Creating a bucket in the AWS documentation.

You will also need an AWS access key and secret key with read-write access to your bucket.

Note: GitHub Enterprise Importer does not delete your archive from AWS after your migration is finished. To reduce storage costs, we recommend configuring auto-deletion of your archive after a period of time. For more information, see Setting lifecycle configuration on a bucket in the AWS documentation.

Настройка учетной записи хранения Хранилище BLOB-объектов Azure

В Azure создайте учетную запись хранения и запишите строку подключения. Дополнительные сведения см. в статье Управление ключами доступа к учетной записи хранения в Документация Майкрософт.

Примечание. GitHub Enterprise Importer не удаляет архив из Хранилище BLOB-объектов Azure после завершения миграции. Чтобы снизить затраты на хранение, рекомендуется настроить автоматическое удаление архива через некоторое время. Дополнительные сведения см. в статье Оптимизация затрат путем автоматического управления жизненным циклом данных в Документация Майкрософт.

Настройка учетных данных хранилища BLOB-объектов

После настройки хранилища BLOB-объектов с помощью поддерживаемого поставщика облачных служб необходимо настроить учетные данные для поставщика хранилища в GitHub:

  • Если вы используете GitHub Enterprise Server 3.8 или более поздней версии, настройте учетные данные в Консоль управления.
  • Если вы используете GitHub Enterprise Server версии 3.7 или более поздней версии, настройте учетные данные в GitHub CLI.

Настройка хранилища BLOB-объектов в Консоль управления экземпляр GitHub Enterprise Server

Примечание: Необходимо настроить хранилище BLOB-объектов в Консоль управления только при использовании GitHub Enterprise Server 3.8 или более поздней версии. Если вы используете версии 3.7 или более поздней версии, настройте учетные данные в GitHub CLI.

После настройки контейнера хранилища AWS S3 или учетной записи хранения Хранилище BLOB-объектов Azure настройте хранилище BLOB-объектов в Консоль управления экземпляр GitHub Enterprise Server. Дополнительные сведения о Консоль управления см. в разделе Администрирование экземпляра из консоли управления.

  1. В учетной записи администратора GitHub Enterprise Cloud в правом верхнем углу любой страницы щелкните .
  2. Если вы еще не на странице "Администратор сайта", в левом верхнем углу щелкните Администратор сайта. 1. На боковой панели Администратор сайта щелкните Консоль управления.
  3. Войдите в Консоль управления.
  4. На верхней панели навигации щелкните Параметры.
  5. В разделе Миграции щелкните Включить миграции GitHub.
  6. При необходимости, чтобы импортировать параметры хранилища, настроенные для GitHub Actions, выберите Копировать параметры хранилища в разделе Действия. Дополнительные сведения см. в разделах Включение GitHub Actions с хранилищем BLOB-объектов Azure и Включение GitHub Actions с помощью хранилища Amazon S3.
  7. Если вы не импортируете параметры хранилища из GitHub Actions, выберите Хранилище BLOB-объектов Azure или Amazon S3 и укажите необходимые сведения.
  8. Щелкните Проверить параметры хранилища.
  9. Нажмите кнопку Сохранить параметры.

Настройка учетных данных хранилища BLOB-объектов в GitHub CLI

Примечание: Необходимо настроить учетные данные хранилища BLOB-объектов в GitHub CLI только при использовании GitHub Enterprise Server версии 3.7 или ниже. Если вы используете версию 3.8 или более позднюю, настройте хранилище BLOB-объектов в Консоль управления.

Если вы настроите учетные данные хранилища BLOB-объектов в GitHub CLI, вы не сможете выполнить миграцию, если объем экспорта источника Git или метаданных превышает 2 ГБ. Чтобы выполнить эти миграции, обновите GitHub Enterprise Server 3.8 или более поздней версии.

Настройка учетных данных AWS S3 в GitHub CLI

Когда вы будете готовы выполнить миграцию, необходимо указать учетные данные AWS для GitHub CLI: регион, ключ доступа, секретный ключ и маркер сеанса (при необходимости). Их можно передать в качестве аргументов или задать переменные среды с именами AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEYи AWS_SESSION_TOKEN.

Также необходимо передать имя контейнера S3 с помощью аргумента --aws-bucket-name .

Настройка учетных данных Хранилище BLOB-объектов Azure учетной записи в GitHub CLI

Когда вы будете готовы выполнить миграцию, вы можете передать строку подключения в GitHub CLI в качестве аргумента или передать ее с помощью переменной среды с именем AZURE_STORAGE_CONNECTION_STRING.

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

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

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

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

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

Этот шаг необходимо выполнить с компьютера, который может получить доступ к API для экземпляр GitHub Enterprise Server. Если вы можете получить доступ к экземпляру из браузера, компьютер имеет правильный доступ.

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

Для GitHub Enterprise Server 3.8 или более поздней версии, а также если вы используете версию 3.7 или более позднюю версию с Хранилище BLOB-объектов Azure, используйте следующие флаги:

Shell
gh gei generate-script --github-source-org SOURCE \
  --github-target-org DESTINATION \
  --output FILENAME \
  --ghes-api-url GHES-API-URL

Если вы используете GitHub Enterprise Server 3.7 или более поздней версии с AWS S3, используйте следующие флаги:

Shell
gh gei generate-script --github-source-org SOURCE \
  --github-target-org DESTINATION \
  --output FILENAME \
  --ghes-api-url GHES-API-URL \
  --aws-bucket-name AWS-BUCKET-NAME

Если экземпляр GitHub Enterprise Server использует самозаверяющий или недопустимый SSL-сертификат, используйте --no-ssl-verify флаг . При использовании этого флага GitHub CLI пропустит проверку SSL-сертификата только при извлечении данных из экземпляра. Все остальные вызовы будут проверять SSL.

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. GHES-API-URL | URL-адрес API экземпляр GitHub Enterprise Server, например https://myghes.com/api/v3 AWS-BUCKET-NAME | Имя контейнера AWS S3

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

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 переноса репозитория без выпусков.

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

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

При переносе репозиториев GEI extension of the GitHub CLI выполняет следующие действия:

  1. Подключается к экземпляр GitHub Enterprise Server и создает два архива миграции для каждого репозитория: один для источника Git и один для метаданных.
  2. Отправляет архивы миграции в выбранный поставщик хранилища BLOB-объектов.
  3. Начинает миграцию в GitHub Enterprise Cloud, используя URL-адреса архивов, хранящихся у поставщика хранилища BLOB-объектов.
  4. Удаляет архив миграции.

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

При миграции с GitHub Enterprise Server 3.7 или более ранней версии перед запуском скрипта необходимо задать дополнительные переменные среды для проверки подлинности в поставщике хранилища BLOB-объектов.

  • Для Хранилище BLOB-объектов Azure задайте AZURE_STORAGE_CONNECTION_STRING строку подключения для учетной записи хранения Azure.

    Поддерживаются только строки подключения, использующие ключи доступа к учетной записи хранения. Строки подключения, использующие подписанные URL-адреса (SAS), не поддерживаются. Дополнительные сведения о ключах доступа к учетной записи хранения см. в статье Управление ключами доступа к учетной записи хранения в документации по Azure.

  • Для AWS S3 задайте следующие переменные среды.

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

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

Этот шаг необходимо выполнить с компьютера, который может получить доступ к API для экземпляр GitHub Enterprise Server. Если вы можете получить доступ к экземпляру из браузера, компьютер имеет правильный доступ.

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

Если вы используете GitHub Enterprise Server 3.8 или более поздней версии, используйте следующие флаги:

Shell
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME --ghes-api-url GHES-API-URL

Если вы выполняете миграцию с GitHub Enterprise Server 3.7 или более ранней версии и используете Хранилище BLOB-объектов Azure в качестве поставщика хранилища BLOB-объектов, используйте следующие флаги для проверки подлинности:

Shell
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \
    --ghes-api-url GHES-API-URL --azure-storage-connection-string "AZURE_STORAGE_CONNECTION_STRING"

Если вы выполняете миграцию с GitHub Enterprise Server 3.7 или более ранней версии и используете Amazon S3 в качестве поставщика хранилища BLOB-объектов, используйте следующие флаги для проверки подлинности:

Shell
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \
    --ghes-api-url GHES-API-URL --aws-bucket-name "AWS-BUCKET-NAME"

Если экземпляр GitHub Enterprise Server использует самозаверяющий или недопустимый SSL-сертификат, используйте --no-ssl-verify флаг . При использовании этого флага GitHub CLI пропустит проверку SSL-сертификата только при извлечении данных из экземпляра. Все остальные вызовы будут проверять SSL.

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

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

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

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

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

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

После завершения миграции рекомендуется удалить архивы из контейнера хранилища. Если вы планируете выполнить дополнительные миграции, удалите архив, помещенный в контейнер хранилища с помощью ADO2GH extension. Если миграция завершена, вы можете удалить весь контейнер.