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

Репозитории можно перенести с GitHub Enterprise Server на GitHub Enterprise Cloud, используя GitHub CLI или API.

Tool navigation

В этой статье

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

Если вы решили использовать API, вам потребуется написать собственные скрипты или использовать HTTP-клиент, такой как бессонница. Дополнительные сведения о начале работы с API GitHubсм. в разделе[ "AUTOTITLE" иНачало работы с REST API](/graphql/guides/forming-calls-with-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".
  • Убедитесь, что вы понимаете данные, которые будут перенесены, и известные ограничения поддержки импорта. Дополнительные сведения см. в разделе "Сведения о миграции между продуктами GitHub".
  • Хотя и не требуется, рекомендуется остановить работу во время рабочей миграции. Importer не поддерживает разностную миграцию, поэтому любые изменения, которые происходят во время миграции, не будут переноситься. Если вы решили не останавливать работу во время рабочей миграции, необходимо вручную перенести эти изменения.
  • В исходных и конечных организациях необходимо либо владелец организации, либо предоставить роль миграции. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.
  • Если вы используете GitHub Enterprise Server 3.8 или более поздней версии, вам потребуется доступ к данным Консоль управления.

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

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

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

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

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

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

Примечание. При использовании GitHub Enterprise Server версии 3.8 или более поздней необходимо настроить хранилище BLOB-объектов. Если вы используете 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

В AWS настройте контейнер S3. Дополнительные сведения см. в разделе "Создание контейнера " в документации ПО AWS.

Вам также потребуется ключ доступа AWS и секретный ключ со следующими разрешениями:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucketMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::github-migration-bucket",
                "arn:aws:s3:::github-migration-bucket/*"
            ]
        }
    ]
}

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

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

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

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

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

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

  1. В учетной записи администратора GitHub Enterprise Server, в правом верхнем углу любой страницы щелкните .

  2. Если вы еще не на странице "Администратор сайта" в левом верхнем углу щелкните "Администратор сайта". 1. На боковой панели " "Администратор сайта" щелкните Консоль управления.

  3. Войдите в Консоль управления.

  4. В верхней панели навигации щелкните Параметры.

  5. В разделе "Миграции" нажмите кнопку "Включить" GitHub Миграции.

  6. При необходимости для импорта параметров хранилища, настроенных для GitHub Actions, выберите "Копировать служба хранилища" из действий. Дополнительные сведения см. в статье "Включение действий GitHub с хранилищем BLOB-объектов Azure" и "Включение действий GitHub с хранилищем Amazon S3".

    Примечание. После копирования параметров хранилища может потребоваться обновить конфигурацию облачной учетной записи хранения, чтобы работать с GitHub Enterprise Importer. В частности, необходимо убедиться, что разрешены IP-адреса GitHub. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.

  7. Если параметры хранилища не импортируются из GitHub Actions, выберите Хранилище BLOB-объектов Azure или Amazon S3 и заполните необходимые сведения.

    Примечание. Если вы используете Amazon S3, необходимо задать URL-адрес службы AWS для стандартной конечной точки региона AWS, в котором находится контейнер. Например, если контейнер находится в регионе eu-west-1 , будет указан https://s3.eu-west-1.amazonaws.comURL-адрес службы AWS. Сеть экземпляра GitHub Enterprise Server должна разрешить доступ к этому узлу. Конечные точки шлюза не поддерживаются, например bucket.vpce-0e25b8cdd720f900e-argc85vg.s3.eu-west-1.vpce.amazonaws.com. Дополнительные сведения о конечных точках шлюза см. в разделе "Конечные точки шлюза" для Amazon S3 в документации AWS.

  8. Щелкните " Тестировать параметры хранилища".

  9. Нажмите кнопку Сохранить параметры.

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

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

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

Переменная запросаDescription
nameИмя источника миграции. Это имя для собственной ссылки, поэтому можно использовать любую строку.
ownerIdИдентификатор организации в GitHub Enterprise Cloud.
urlURL-адрес для экземпляр GitHub Enterprise Server. Этот URL-адрес не должен быть доступен из 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 репозитория и одного для создания архива метаданных репозитория (например, проблем и запросов на вытягивание).

Чтобы создать исходный архив Git, выполните POST запрос 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,
  // ...
}

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

Создание архивов может занять некоторое время в зависимости от объема данных. Вы можете регулярно проверка состояние двух миграций с помощью 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",
  // ...
}

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

Примечание. Если миграция перемещается в 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 и один для метаданных.

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

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

Шаг 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.

Шаг 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
    }
  }
}
Переменная запросаDescription
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.
accessTokenpersonal access token для источника.
targetRepoVisibilityВидимость нового репозитория. Должно быть private, public или internal. Если этот параметр не задан, репозиторий переносится как закрытый.
gitArchiveUrlURL-адрес для исходного архива Git { % variables.product.prodname_ghe_cloud %}.
metadataArchiveUrlURL-адрес ,доступный для архива метаданных GitHub Enterprise Cloud.
sourceRepositoryUrlURL-адрес репозитория в экземпляре GitHub Enterprise Server. Это необходимо, но GitHub Enterprise Cloud не будет напрямую взаимодействовать с экземпляром GitHub Enterprise Server.

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

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

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

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

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

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

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

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

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

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

    Примечание. Вам нужна версия 2.4.0 или более позднюю версию GitHub CLI. Вы можете проверка версию, установленную gh --version с помощью команды.

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

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

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

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

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

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

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

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

В AWS настройте контейнер S3. Дополнительные сведения см. в разделе "Создание контейнера " в документации ПО AWS.

Вам также потребуется ключ доступа AWS и секретный ключ со следующими разрешениями:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucketMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::github-migration-bucket",
                "arn:aws:s3:::github-migration-bucket/*"
            ]
        }
    ]
}

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

Настройка учетной записи хранения Хранилище 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 Server, в правом верхнем углу любой страницы щелкните .

  2. Если вы еще не на странице "Администратор сайта" в левом верхнем углу щелкните "Администратор сайта". 1. На боковой панели " "Администратор сайта" щелкните Консоль управления.

  3. Войдите в Консоль управления.

  4. В верхней панели навигации щелкните Параметры.

  5. В разделе "Миграции" нажмите кнопку "Включить" GitHub Миграции.

  6. При необходимости для импорта параметров хранилища, настроенных для GitHub Actions, выберите "Копировать служба хранилища" из действий. Дополнительные сведения см. в статье "Включение действий GitHub с хранилищем BLOB-объектов Azure" и "Включение действий GitHub с хранилищем Amazon S3".

    Примечание. После копирования параметров хранилища может потребоваться обновить конфигурацию облачной учетной записи хранения, чтобы работать с GitHub Enterprise Importer. В частности, необходимо убедиться, что разрешены IP-адреса GitHub. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.

  7. Если параметры хранилища не импортируются из GitHub Actions, выберите Хранилище BLOB-объектов Azure или Amazon S3 и заполните необходимые сведения.

    Примечание. Если вы используете Amazon S3, необходимо задать URL-адрес службы AWS для стандартной конечной точки региона AWS, в котором находится контейнер. Например, если контейнер находится в регионе eu-west-1 , будет указан https://s3.eu-west-1.amazonaws.comURL-адрес службы AWS. Сеть экземпляра GitHub Enterprise Server должна разрешить доступ к этому узлу. Конечные точки шлюза не поддерживаются, например bucket.vpce-0e25b8cdd720f900e-argc85vg.s3.eu-west-1.vpce.amazonaws.com. Дополнительные сведения о конечных точках шлюза см. в разделе "Конечные точки шлюза" для Amazon S3 в документации AWS.

  8. Щелкните " Тестировать параметры хранилища".

  9. Нажмите кнопку Сохранить параметры.

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

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

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

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

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

Кроме того, необходимо передать имя контейнера 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, ](https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-macos?view=powershell-7.2)чтобы запустить его.

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

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

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

Если вы хотите, чтобы скрипт скачал журнал миграции для каждого перенесенного репозитория, добавьте --download-migration-logs флаг. Дополнительные сведения о журналах миграции см. в разделе "Доступ к журналам миграции для GitHub Enterprise Importer".

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

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

Если вы используете терминал, используйте .ps1 расширение файла в качестве созданного скрипта, чтобы запустить PowerShell. Вы можете установить PowerShell для Mac или Linux.
GHES-API-URLURL-адрес для API экземпляр GitHub Enterprise Server, например https://myghes.com/api/v3
AWS-BUCKET-NAMEИмя контейнера для контейнера AWS S3

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

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

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

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

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

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

При переносе репозиториев 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.

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

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

    • AWS_ACCESS_KEY: ключ доступа для контейнера
    • AWS_SECRET_KEY: секретный ключ для контейнера
    • AWS_REGION: регион AWS, в котором находится контейнер
    • AWS_SESSION_TOKEN: маркер сеанса, если вы используете временные учетные данные AWS (см. сведения об использовании временных учетных данных с ресурсами AWS в документации AWS).

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

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

Если вы используете 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 Используйте флаг для переноса репозитория без выпусков.

GHES-API-URL | URL-адрес для API экземпляр GitHub Enterprise Server, например https://myghes.com/api/v3 AZURE_STORAGE_CONNECTION_STRING | Строка подключения для учетной записи хранения Azure.

Обязательно процитировать строка подключения, содержащий символы, которые, скорее всего, будут интерпретированы оболочкой. AWS-BUCKET-NAME | Имя контейнера для контейнера AWS S3

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

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

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

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

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

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