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

Если вы решили использовать 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, чтобы определить, откуда выполняется миграция
4. Для каждого репозитория, который требуется перенести, повторите эти действия.
   • Использование REST API в экземпляр GitHub Enterprise Server для создания архивов миграции для репозитория
   • Отправка архивов миграции в расположение, к которым можно получить доступ с помощью GitHub
   • Запустите миграцию с помощью API GraphQL для назначения миграции, передавая URL-адреса архива
   • Проверьте состояние миграции с помощью API GraphQL
   • Проверка миграции и проверка журнала ошибок

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

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

Настройка хранилища 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/*"
            ]
        }
    ]
}

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

В 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. Нажмите кнопку Сохранить параметры.

Разрешение сетевого доступа

Если вы настроили правила брандмауэра в учетной записи хранения, убедитесь, что у вас есть доступ к диапазонам IP-адресов для назначения миграции. См. раздел "Управление доступом к миграции между продуктами GitHub".

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

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

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

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, используя наш API GraphQL.

Если вы используете GitHub Enterprise Server 3.7 или более поздней версии, необходимо сначала создать URL-адреса для архивов, доступных GitHub. Большинство клиентов предпочитают отправлять архивы в службу хранилища 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 потерял соединение и не сможет повторно подключиться к миграции.
githubPat	personal access token для целевой организации на GitHub Enterprise Cloud.
accessToken	personal access token для источника.
targetRepoVisibility	Видимость нового репозитория. Должно быть private, public или internal. Если этот параметр не задан, репозиторий переносится как закрытый.
gitArchiveUrl	URL-адрес для исходного архива Git { % variables.product.prodname_ghe_cloud %}.
metadataArchiveUrl	URL-адрес ,доступный для архива метаданных GitHub Enterprise Cloud.
sourceRepositoryUrl	URL-адрес репозитория в экземпляре GitHub Enterprise Server. Это необходимо, но GitHub Enterprise Cloud не будет напрямую взаимодействовать с экземпляром GitHub Enterprise Server.

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

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

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

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

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

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

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

gh extension upgrade github/gh-gei

{
    "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/*"
            ]
        }
    ]
}

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

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

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

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

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

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

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"

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"

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"

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"

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

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