# Usar o GraphQL para migrar repositórios do GitLab para GitHub Enterprise Cloud Você pode criar suas próprias ferramentas para migrar repositórios do GitLab para GitHub Enterprise Cloud usar a API do GraphQL. > \[!NOTE] Você também pode usar GL2GH extension of the GitHub CLI para executar sua migração. Consulte [Entender as migrações do GitLab para o GitHub](/pt/migrations/using-github-enterprise-importer/migrate-from-gitlab/understand-migrations). ## Etapa 0: Prepare-se para usar a API do GitHub GraphQL Para fazer consultas do GraphQL, você precisará escrever seus scripts ou usar um cliente HTTP como o [Insomnia](https://insomnia.rest/). Para saber mais sobre como começar a usar a API do GraphQL do GitHub, incluindo como se autenticar, confira [Realizar chamadas com o GraphQL](/pt/graphql/guides/forming-calls-with-graphql). Você enviará todas as consultas GraphQL para o **destino** da sua migração. Se você estiver migrando para o GitHub Enterprise Cloud com residência de dados, envie consultas para o ponto de extremidade do subdomínio da sua empresa do GHE.com. ## Etapa 1: Obter a `ownerId` do destino de migração Como proprietário de uma organização no GitHub Enterprise Cloud, use a consulta `GetOrgInfo` para retornar a `ownerId`, também chamada de ID da organização, na organização da qual você deseja ser proprietário dos repositórios migrados. Você precisará da `ownerId` para identificar seu destino de migração. #### Consulta `GetOrgInfo` ```graphql query( $login: String! ){ organization (login: $login) { login id name databaseId } } ``` | Variável da consulta | Descrição | | -------------------- | -------------------------- | | `login` | O nome da sua organização. | #### Resposta `GetOrgInfo` ```json { "data": { "organization": { "login": "Octo", "id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=", "name": "Octo-org", "databaseId": 5610 } } } ``` Neste exemplo, `MDEyOk9yZ2FuaXphdGlvbjU2MTA=` é a ID da organização ou `ownerId`, que usaremos na próxima etapa. ## Etapa 2: Identificar a origem da migração Você pode configurar uma origem de migração usando a consulta `createMigrationSource`. Você precisará fornecer a `ownerId`, ou a ID da organização, coletada da consulta `GetOrgInfo`. Sua origem de migração é sua instância do GitLab. ### `createMigrationSource` mutação ```graphql mutation createMigrationSource($name: String!, $url: String!, $ownerId: ID!) { createMigrationSource(input: {name: $name, url: $url, ownerId: $ownerId, type: GITLAB}) { migrationSource { id name url type } } } ``` Defina `url` como a URL completa da instância do GitLab, como `https://gitlab.com` ou `https://gitlab.example.com`. Lembre-se de usar `GITLAB` para `type`. | Variável da consulta | Descrição | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | `name` | Um nome para a origem da migração. Esse nome se destina à sua referência, ou seja, você pode usar qualquer cadeia de caracteres. | | `ownerId` | A ID da sua organização no GitHub Enterprise Cloud. | ### Resposta `createMigrationSource` ```json { "data": { "createMigrationSource": { "migrationSource": { "id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA", "name": "GitLab Source", "url": "https://gitlab.com", "type": "GITLAB" } } } } ``` Neste exemplo, `MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA` é a ID de origem da migração, que usaremos em uma etapa posterior. ## Etapa 3: Gerar e hospedar seu arquivo de migração As migrações do GitLab são baseadas em arquivos. Em vez de se conectar à instância do GitLab durante a migração, GitHub Enterprise Importer importa um arquivo morto de migração gerado do seu projeto do GitLab. Um arquivo do GitLab é um único arquivo que contém a origem do Git e os metadados do repositório. Antes de iniciar a migração, você deve: 1. Gere um arquivo de migração para o projeto do GitLab que você deseja migrar. 2. Hospede o arquivo morto em uma URL que GitHub Enterprise Cloud pode ser acessada. Você fornecerá essa URL como o `gitArchiveUrl` valor na próxima etapa. ### Gerar arquivos de migração Use a [API de exportação de projeto](https://docs.gitlab.com/api/project_import_export/) do GitLab para exportar o projeto que você deseja migrar. O token usado deve ter o `api` escopo e uma função com permissão para exportar o projeto. Para obter mais informações, consulte [Gerenciar o acesso para uma migração do GitLab para o GitHub](/pt/migrations/using-github-enterprise-importer/migrate-from-gitlab/manage-access). Nas solicitações a seguir, defina a variável de `GITLAB_PAT` ambiente como o token criado em [Gerenciar o acesso para uma migração do GitLab para o GitHub](/pt/migrations/using-github-enterprise-importer/migrate-from-gitlab/manage-access). Substitua `GITLAB-SERVER` pelo host da instância do GitLab, como `gitlab.com`, e substitua `GROUP%2FPROJECT` pelo caminho codificado em URL do seu projeto. Por exemplo, o projeto `acme-group/my-project` é codificado como `acme-group%2Fmy-project`. Para subgrupos aninhados, inclua o caminho completo, como `parent-group%2Fsubgroup%2Fmy-project`. 1. Agende a exportação. ```shell curl --request POST \ --header "PRIVATE-TOKEN: $GITLAB_PAT" \ "https://GITLAB-SERVER/api/v4/projects/GROUP%2FPROJECT/export" ``` 2. Verifique o status da exportação. Repita essa solicitação até `export_status` que seja `finished`. ```shell curl --header "PRIVATE-TOKEN: $GITLAB_PAT" \ "https://GITLAB-SERVER/api/v4/projects/GROUP%2FPROJECT/export" ``` 3. Baixe o arquivo morto. ```shell curl --location \ --header "PRIVATE-TOKEN: $GITLAB_PAT" \ --output archive.tar.gz \ "https://GITLAB-SERVER/api/v4/projects/GROUP%2FPROJECT/export/download" ``` ### Hospedando o arquivo morto Você deve hospedar o arquivo morto em uma URL que GitHub Enterprise Cloud possa ser acessada. Você pode carregar o arquivo morto GitHub-owned blob storage ou usar um provedor de armazenamento de blobs externo. Para obter informações sobre provedores externos, consulte [Configurar o armazenamento de blobs](/pt/migrations/using-github-enterprise-importer/migrate-from-gitlab/configure-storage). Para carregar o arquivo mortoGitHub-owned blob storage, você precisará da ID do banco de dados da sua organização.GitHub Enterprise Cloud Substitua `ORGANIZATION` pelo nome da sua organização para obter essa ID do `id` campo na resposta. ```shell curl --header "Authorization: Bearer YOUR-TOKEN" \ "https://api.github.com/orgs/ORGANIZATION" ``` > \[!NOTE] Se você estiver migrando para GHE.com, substitua `https://api.github.com` pela URL de API base para o subdomínio da sua empresa, como `https://api.octocorp.ghe.com`. Carregue o arquivo morto com uma `POST` solicitação, substituindo `ORGANIZATION-ID` pela ID do banco de dados da sua organização. Essa solicitação funciona para arquivos de até 100 MiB. Para arquivos maiores, use um provedor de armazenamento de blobs externo. ```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] Se você estiver migrando para GHE.com, substitua `uploads.github.com` pelo host de uploads para o subdomínio da sua empresa, como `uploads.octocorp.ghe.com`. A resposta inclui um `uri` no formato `gei://archive/GUID`. Utilize este valor como o `gitArchiveUrl` no passo seguinte. ```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" } ``` ## Etapa 4: Iniciar a migração do repositório Quando você inicia uma migração, um repositório individual e os dados complementares são migrados para um novo repositório do GitHub identificado por você. Caso você deseje mover vários repositórios ao mesmo tempo da mesma organização de origem, coloque várias migrações na fila. É possível executar até cinco migrações de repositório ao mesmo tempo. ### `startRepositoryMigration` mutação ```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 } } } ``` | Variável da consulta | Descrição | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `sourceId` | A origem de migração `id` retornou da mutação `createMigrationSource`. | | `ownerId` | A ID da sua organização no GitHub Enterprise Cloud. | | `repositoryName` | Um nome de repositório exclusivo personalizado não usado atualmente por nenhum dos seus repositórios pertencentes à organização no GitHub Enterprise Cloud. Um problema de log de erros será criado neste repositório quando a migração for concluída ou tiver sido interrompida. | | `continueOnError` | Configuração de migração que permite que a migração continue ao encontrar erros que não causam falha na migração. Deve ser `true` ou `false`. Recomendamos fortemente definir `continueOnError` como `true`, de modo que a migração continue, a menos que o Importer não possa mover a origem do Git ou o Importer tenha perdido a conexão e não possa se reconectar para concluir a migração. | | `githubPat` | O personal access token da sua organização de destino no GitHub Enterprise Cloud. | | `accessToken` | Os dados do personal access token da origem. | | `targetRepoVisibility` | A visibilidade do novo repositório. Deve ser `private`, `public` ou `internal`. Se isso não estiver definido, seu repositório será migrado como privado. | | `gitArchiveUrl` | Uma GitHub Enterprise CloudURL acessível para o arquivo de migração gerado na etapa anterior. As migrações do GitLab usam um único arquivo que contém a origem e os metadados do Git, portanto, você não precisa fornecer um arquivo separado `metadataArchiveUrl`. \| `sourceRepositoryUrl` | A URL do repositório de origem no GitLab, usando o formato `https://GITLAB-SERVER/{group}/{project}`. Para subgrupos aninhados, inclua o caminho completo, como `https://GITLAB-SERVER/{parent-group}/{subgroup}/{project}`. GitHub Enterprise Cloud não se conecta a essa URL durante a migração; é gravado para referência. Como as migrações do GitLab são baseadas em arquivos, GitHub Enterprise Cloud não se conecta ao GitLab durante a migração. A `accessToken` variável é exigida pela mutação, mas não é usada, portanto, você pode defini-la como qualquer valor de espaço reservado, como `not-used`. Para ver os requisitos, consulte personal access token. Na próxima etapa, você usará a ID de migração retornada da mutação `startRepositoryMigration` para verificar o status da migração. ## Etapa 5: Verificar o status da migração Para detectar qualquer falha de migração e garantir que a migração esteja funcionando, verifique o status da migração usando a consulta `getMigration`. Você também pode verificar o status de várias migrações com `getMigrations`. A consulta `getMigration` retornará com um status para informar se a migração é `queued`, `in progress`, `failed` ou `completed`. Em caso de falha na migração, o Importer fornecerá um motivo para a falha. #### Consulta `getMigration` ```graphql query ( $id: ID! ){ node( id: $id ) { ... on Migration { id sourceUrl migrationSource { name } state failureReason } } } ``` | Variável da consulta | Descrição | | -------------------- | ----------------------------------------------------------------------------------------------------------- | | `id` | A `id` da migração que [a mutação `startRepositoryMigration`](#startrepositorymigration-mutation) retornou. | ## Etapa 6: Validar a migração e verificar o log de erros Para concluir a migração, recomendamos que você verifique o problema "Log de Migração". Esse problema é criado no GitHub no repositório de destino. ![Captura de tela de um problema com o título "Log de Migração". O segundo comentário no problema inclui os logs de uma migração.](/assets/images/help/github-enterprise-importer/migration-log-issue.png) Por fim, recomendamos que você revise os repositórios migrados para uma verificação de integridade. ## Leitura adicional * [Tarefas de acompanhamento](/pt/migrations/using-github-enterprise-importer/migrate-from-gitlab/follow-up-tasks)