Использование GraphQL для переноса репозиториев из GitLab в GitHub Enterprise Cloud

Примечание.

Вы также можете использовать GL2GH extension of the GitHub CLI его для проведения миграции. См . раздел AUTOTITLE.

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

Чтобы сделать запросы 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 из запроса.

Источник миграции — это экземпляр GitLab.

`createMigrationSource` мутация

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

Задайте url полный URL-адрес экземпляра GitLab, например https://gitlab.com или https://gitlab.example.com. Обязательно используйте GITLAB для type.

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

`createMigrationSource` ответ

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
        "name": "GitLab Source",
        "url": "https://gitlab.com",
        "type": "GITLAB"
      }
    }
  }
}

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

Шаг 3. Создание и размещение архива миграции

Миграции из GitLab основаны на архивах. Вместо подключения к экземпляру GitLab во время миграции импортирует архив миграции, GitHub Enterprise Importer создаваемый из проекта GitLab. Архив GitLab — это один файл, содержащий как источник Git, так и метаданные репозитория.

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

Создайте архив миграции для проекта GitLab, который вы хотите перенести.
Разместите архив по URL-адресу, к которому GitHub Enterprise Cloud можно получить доступ.

Этот URL-адрес будет указан в качестве gitArchiveUrl значения на следующем шаге.

Создание архива миграции

Используйте API экспорта проекта GitLab для экспорта проекта, который требуется перенести. Используемый маркер должен иметь api область и роль с разрешением на экспорт проекта. Дополнительные сведения см. в разделе Управление доступом для миграции из GitLab в GitHub.

В следующих запросах задайте GITLAB_PAT переменную среды маркеру, созданному в Управление доступом для миграции из GitLab в GitHub. Замените GITLAB-SERVER на узел экземпляра GitLab, например gitlab.com, и замените GROUP%2FPROJECT URL-адресом проекта. Например, проект acme-group/my-project закодирован как acme-group%2Fmy-project. Для вложенных подгрупп включите полный путь, например parent-group%2Fsubgroup%2Fmy-project.

Запланируйте экспорт.

curl --request POST \
  --header "PRIVATE-TOKEN: $GITLAB_PAT" \
  "https://GITLAB-SERVER/api/v4/projects/GROUP%2FPROJECT/export"

Проверьте состояние экспорта. Повторите этот запрос, пока не export_status будет finished.
```
curl --header "PRIVATE-TOKEN: $GITLAB_PAT" \
  "https://GITLAB-SERVER/api/v4/projects/GROUP%2FPROJECT/export"
```

Скачайте архив.

curl --location \
  --header "PRIVATE-TOKEN: $GITLAB_PAT" \
  --output archive.tar.gz \
  "https://GITLAB-SERVER/api/v4/projects/GROUP%2FPROJECT/export/download"

Размещение архива

Необходимо разместить архив по URL-адресу, к которому GitHub Enterprise Cloud можно получить доступ. Вы можете отправить архив GitHub-owned blob storage или использовать внешний поставщик хранилища BLOB-объектов. Сведения о внешних поставщиках см. в разделе Настройка хранилища BLOB-объектов.

Чтобы отправить архив GitHub-owned blob storage, вам потребуется идентификатор базы данных вашей организации GitHub Enterprise Cloud. Замените ORGANIZATION именем организации, чтобы получить этот идентификатор из id поля в ответе.

curl --header "Authorization: Bearer YOUR-TOKEN" \
  "https://api.github.com/orgs/ORGANIZATION"

Примечание.

Если выполняется миграция GHE.com, замените https://api.github.com базовым URL-адресом API для поддомена предприятия, например https://api.octocorp.ghe.com.

Отправьте архив с запросом POST , заменив ORGANIZATION-ID идентификатором базы данных вашей организации. Этот запрос работает для архивов до 100 МиБ. Для более крупных архивов используйте внешний поставщик хранилища BLOB-объектов.

curl --request POST \
  --header "Authorization: Bearer YOUR-TOKEN" \
  --header "Content-Type: application/octet-stream" \
  --data-binary @archive.tar.gz \
  "https://uploads.github.com/organizations/ORGANIZATION-ID/gei/archive?name=archive.tar.gz"

Примечание.

Если выполняется миграция GHE.com, замените uploads.github.com узел отправки для поддомена предприятия, например uploads.octocorp.ghe.com.

Ответ включает в себя uri формат gei://archive/GUID. Используйте это значение в качестве на gitArchiveUrl следующем шаге.

{
  "guid": "ff7b1a25-aa10-41a9-8e42-f170304b1c0d",
  "node_id": "MA_kgDaACRmZjdiMWEyNS1hYTEwLTQxYTktOGU0Mi1mMTcwMzA0YjFjMGQ",
  "name": "archive.tar.gz",
  "size": 7103,
  "uri": "gei://archive/ff7b1a25-aa10-41a9-8e42-f170304b1c0d",
  "created_at": "2024-11-13T12:35:45.761-08:00"
}

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

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

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

`startRepositoryMigration` мутация

mutation startRepositoryMigration (
  $sourceId: ID!,
  $ownerId: ID!,
  $sourceRepositoryUrl: URI!,
  $repositoryName: String!,
  $continueOnError: Boolean!,
  $accessToken: String!,
  $githubPat: String!,
  $gitArchiveUrl: String!,
  $targetRepoVisibility: String!
){
  startRepositoryMigration( input: {
    sourceId: $sourceId,
    ownerId: $ownerId,
    repositoryName: $repositoryName,
    continueOnError: $continueOnError,
    accessToken: $accessToken,
    githubPat: $githubPat,
    targetRepoVisibility: $targetRepoVisibility,
    gitArchiveUrl: $gitArchiveUrl,
    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-адрес GitHub Enterprise Cloud, доступный для архива миграции, созданного на предыдущем шаге. Миграции GitLab используют один архив, содержащий источник Git и метаданные, поэтому вам не нужно предоставлять отдельный metadataArchiveUrlархив.

| sourceRepositoryUrl | URL-адрес исходного репозитория в GitLab с помощью формата https://GITLAB-SERVER/{group}/{project}. Для вложенных подгрупп включите полный путь, например https://GITLAB-SERVER/{parent-group}/{subgroup}/{project}. GitHub Enterprise Cloud не подключается к этому URL-адресу во время миграции; он записывается для ссылки.

Так как миграции GitLab основаны на архивах, GitHub Enterprise Cloud во время миграции не подключается к GitLab. Переменная accessToken требуется для изменения, но не используется, поэтому ее можно задать для любого значения заполнителя, например not-used.

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

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

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

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

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

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

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

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

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

Дальнейшие задачи

Использование GraphQL для переноса репозиториев из GitLab в GitHub Enterprise Cloud

В этой статье