# Использование GraphQL для переноса репозиториев из GitLab в GitHub Enterprise Cloud Вы можете создать собственные средства для переноса репозиториев из GitLab в GitHub Enterprise Cloud использование API GraphQL. > \[!NOTE] Вы также можете использовать GL2GH extension of the GitHub CLI его для проведения миграции. См [. раздел AUTOTITLE](/ru/migrations/using-github-enterprise-importer/migrate-from-gitlab/understand-migrations). ## Шаг 0: Подготовьтесь к использованию GitHub API GraphQL Чтобы сделать запросы GraphQL, вам потребуется написать собственные скрипты или использовать HTTP-клиент, такой как [бессонница](https://insomnia.rest/). Дополнительные сведения о начале работы с API GraphQL GitHub GraphQL, включая проверку подлинности, см. в статье [Формирование вызовов с помощью GraphQL](/ru/graphql/guides/forming-calls-with-graphql). Все запросы GraphQL отправляются в **место назначения** миграции. Если вы переносите данные GitHub Enterprise Cloud с размещением данных, обязательно отправьте запросы в конечную точку поддомена вашего предприятия GHE.com. ## Шаг 1. Получение `ownerId` назначения миграции В качестве владелец организации в GitHub Enterprise Cloudиспользуйте `GetOrgInfo` запрос для возврата `ownerId`идентификатора организации, которая также называется идентификатором организации, для которой требуется принадлежать перенесенные репозитории. Вам потребуется `ownerId` определить назначение миграции. #### `GetOrgInfo` запрос ```graphql query( $login: String! ){ organization (login: $login) { login id name databaseId } } ``` | Переменная запроса | Description | | ------------------ | ---------------------- | | `login` | Имя вашей организации. | #### `GetOrgInfo` ответ ```json { "data": { "organization": { "login": "Octo", "id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=", "name": "Octo-org", "databaseId": 5610 } } } ``` В этом примере `MDEyOk9yZ2FuaXphdGlvbjU2MTA=` — это идентификатор организации или `ownerId`идентификатор организации, который мы будем использовать на следующем шаге. ## Шаг 2. Определение места миграции из Вы можете настроить источник миграции с помощью `createMigrationSource` запроса. Вам потребуется указать `ownerId`идентификатор организации, собранный `GetOrgInfo` из запроса. Источник миграции — это экземпляр GitLab. ### `createMigrationSource` мутация ```graphql 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` ответ ```json { "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, так и метаданные репозитория. Перед началом миграции необходимо выполнить следующие действия. 1. Создайте архив миграции для проекта GitLab, который вы хотите перенести. 2. Разместите архив по URL-адресу, к которому GitHub Enterprise Cloud можно получить доступ. Этот URL-адрес будет указан в качестве `gitArchiveUrl` значения на следующем шаге. ### Создание архива миграции Используйте [API экспорта проекта](https://docs.gitlab.com/api/project_import_export/) GitLab для экспорта проекта, который требуется перенести. Используемый маркер должен иметь `api` область и роль с разрешением на экспорт проекта. Дополнительные сведения см. в разделе [Управление доступом для миграции из GitLab в GitHub](/ru/migrations/using-github-enterprise-importer/migrate-from-gitlab/manage-access). В следующих запросах задайте `GITLAB_PAT` переменную среды маркеру, созданному в [Управление доступом для миграции из GitLab в GitHub](/ru/migrations/using-github-enterprise-importer/migrate-from-gitlab/manage-access). Замените `GITLAB-SERVER` на узел экземпляра GitLab, например `gitlab.com`, и замените `GROUP%2FPROJECT` URL-адресом проекта. Например, проект `acme-group/my-project` закодирован как `acme-group%2Fmy-project`. Для вложенных подгрупп включите полный путь, например `parent-group%2Fsubgroup%2Fmy-project`. 1. Запланируйте экспорт. ```shell curl --request POST \ --header "PRIVATE-TOKEN: $GITLAB_PAT" \ "https://GITLAB-SERVER/api/v4/projects/GROUP%2FPROJECT/export" ``` 2. Проверьте состояние экспорта. Повторите этот запрос, пока не `export_status` будет `finished`. ```shell curl --header "PRIVATE-TOKEN: $GITLAB_PAT" \ "https://GITLAB-SERVER/api/v4/projects/GROUP%2FPROJECT/export" ``` 3. Скачайте архив. ```shell 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-объектов](/ru/migrations/using-github-enterprise-importer/migrate-from-gitlab/configure-storage). Чтобы отправить архив GitHub-owned blob storage, вам потребуется идентификатор базы данных вашей организации GitHub Enterprise Cloud. Замените `ORGANIZATION` именем организации, чтобы получить этот идентификатор из `id` поля в ответе. ```shell curl --header "Authorization: Bearer YOUR-TOKEN" \ "https://api.github.com/orgs/ORGANIZATION" ``` > \[!NOTE] Если выполняется миграция GHE.com, замените `https://api.github.com` базовым URL-адресом API для поддомена предприятия, например `https://api.octocorp.ghe.com`. Отправьте архив с запросом `POST` , заменив `ORGANIZATION-ID` идентификатором базы данных вашей организации. Этот запрос работает для архивов до 100 МиБ. Для более крупных архивов используйте внешний поставщик хранилища BLOB-объектов. ```shell 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" ``` > \[!NOTE] Если выполняется миграция GHE.com, замените `uploads.github.com` узел отправки для поддомена предприятия, например `uploads.octocorp.ghe.com`. Ответ включает в себя `uri` формат `gei://archive/GUID`. Используйте это значение в качестве на `gitArchiveUrl` следующем шаге. ```json { "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` мутация ```graphql 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](/ru/migrations/using-github-enterprise-importer/migrate-from-gitlab/manage-access). На следующем шаге вы будете использовать идентификатор миграции, возвращенный из `startRepositoryMigration` изменения, чтобы проверить состояние миграции. ## Шаг 5. Проверка состояния миграции Чтобы обнаружить любые сбои миграции и убедиться, что миграция работает, можно проверить состояние миграции с помощью `getMigration` запроса. Вы также можете проверить состояние нескольких миграций.`getMigrations` Запрос `getMigration` возвращается с состоянием, чтобы сообщить, является `queued`ли миграция , `in progress``failed`или `completed`. Если миграция завершилась сбоем, Importer предоставит причину сбоя. #### `getMigration` запрос ```graphql query ( $id: ID! ){ node( id: $id ) { ... on Migration { id sourceUrl migrationSource { name } state failureReason } } } ``` | Переменная запроса | Description | | ------------------ | ---------------------------------------------------------------------------------------------------- | | `id` | Миграция`id`, возвращаемая [мутацией`startRepositoryMigration`](#startrepositorymigration-mutation). | ## Шаг 6. Проверка миграции и проверка журнала ошибок Чтобы завершить миграцию, рекомендуется проверить проблему журнала миграции. Эта проблема создается на GitHub в целевом репозитории. ![Снимок экрана: проблема с заголовком "Журнал миграции". Второй комментарий в этой проблеме включает журналы для миграции.](/assets/images/help/github-enterprise-importer/migration-log-issue.png) Наконец, рекомендуется просмотреть перенесенные репозитории для проверки звука. ## Дополнительные материалы * [Дальнейшие задачи](/ru/migrations/using-github-enterprise-importer/migrate-from-gitlab/follow-up-tasks)