Como migrar repositórios do GitHub.com para o GitHub Enterprise Cloud

Sobre as migrações de repositório com o GitHub Enterprise Importer

As migrações para o GitHub Enterprise Cloud incluem migrações entre contas do GitHub.com e, caso você esteja adotando o residência de dados, migrações para o subdomínio da sua empresa do GHE.com.

Você pode executar a migração com a GitHub CLI ou a API.

A GitHub CLI simplifica o processo de migração e é recomendada para a maioria dos clientes. Os clientes avançados com necessidades de personalização intensiva podem usar a API para criar integrações próprias ao GitHub Enterprise Importer.

Para ver instruções para usar a API, use o alternador de ferramentas na parte superior da página.

Para ver instruções para usar os dados da GitHub CLI, use o alternador de ferramentas na parte superior da página.

Pré-requisitos

Recomendamos fortemente que você faça uma execução de avaliação da migração e conclua a migração de produção logo em seguida. Para saber mais sobre execuções de avaliação, confira "Visão geral de uma migração entre produtos GitHub".
Certifique-se de entender os dados que serão migrados e as limitações de suporte conhecidas do Importador. Para obter mais informações, confira "Sobre migrações entre produtos GitHub".
Embora não seja necessário, recomendamos interromper o trabalho durante a migração de produção. O Importer não dá suporte a migrações delta, ou seja, as alterações que ocorrerem durante a migração não serão migradas. Se você optar por não interromper o trabalho durante a migração de produção, precisará migrar manualmente essas alterações.
Na organização de origem e de destino, você precisa ser um proprietário da organização ou receber a função de migrador. Para obter mais informações, confira "Gerenciando o acesso para uma migração entre produtos GitHub".

Etapa 0: Preparar-se para usar a API do GraphQL do GitHub

Para fazer consultas do GraphQL, você precisará escrever seus scripts ou usar um cliente HTTP como o Insomnia.

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".

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`

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`

{
  "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.

A origem de migração é uma organização do GitHub.com.

Mutação `createMigrationSource`

mutation createMigrationSource($name: String!, $ownerId: ID!) {
  createMigrationSource(input: {name: $name, url: "https://github.com", ownerId: $ownerId, type: GITHUB_ARCHIVE}) {
    migrationSource {
      id
      name
      url
      type
    }
  }
}

Observação: use GITHUB_ARCHIVE 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`

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
        "name": "GitHub.com Source",
        "url": "https://github.com",
        "type": "GITHUB_SOURCE"
      }
    }
  }
}

Neste exemplo, MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA é a ID de origem de migração, que usaremos na próxima etapa.

Etapa 3: 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.

Mutação `startRepositoryMigration`

mutation startRepositoryMigration (
  $sourceId: ID!,
  $ownerId: ID!,
  $sourceRepositoryUrl: URI!,
  $repositoryName: String!,
  $continueOnError: Boolean!,
  $accessToken: String!,
  $githubPat: String!,
  $targetRepoVisibility: String!
){
  startRepositoryMigration( input: {
    sourceId: $sourceId,
    ownerId: $ownerId,
    repositoryName: $repositoryName,
    continueOnError: $continueOnError,
    accessToken: $accessToken,
    githubPat: $githubPat,
    targetRepoVisibility: $targetRepoVisibility
    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.
`sourceRepositoryUrl`	A URL do repositório de origem, usando o formato `https://github.com/{organization}/{repository}`.

Para ver os requisitos do personal access token, confira "Gerenciando o acesso para uma migração entre produtos GitHub".

Na próxima etapa, você usará a ID de migração retornada da mutação startRepositoryMigration para verificar o status da migração.

Etapa 4: 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`

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` retornou.

Etapa 5: 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.

Por fim, recomendamos que você revise os repositórios migrados para uma verificação de integridade.

Etapa 1: Instalar a GEI extension of the GitHub CLI

Se essa for sua primeira migração, você precisará instalar a GEI extension of the GitHub CLI. Para obter mais informações sobre a GitHub CLI, confira "Sobre o a CLI do GitHub".

Como alternativa, você pode baixar um binário autônomo na página de versões do repositório github/gh-gei. Você pode executar o binário diretamente, sem o prefixo gh.

Instale a GitHub CLI. Para obter instruções de instalação para GitHub CLI, veja o repositório GitHub CLI.

Observação: você precisa ter a versão 2.4.0 ou mais recente da GitHub CLI. Verifique a versão instalada com o comando gh --version.

Instale o GEI extension.

Shell

gh extension install github/gh-gei

gh extension install github/gh-gei

Sempre que precisar de ajuda com a GEI extension, use o sinalizador --help com um comando. Por exemplo, gh gei --help listará todos os comandos disponíveis, e gh gei migrate-repo --help listará todas as opções disponíveis para o comando migrate-repo.

Etapa 2: Atualizar a GEI extension of the GitHub CLI

A GEI extension é atualizada semanalmente. Para garantir que você esteja usando a última versão, atualize a extensão.

gh extension upgrade github/gh-gei

Etapa 3: Definir variáveis de ambiente

Para usar a GEI extension para migrar para o GitHub Enterprise Cloud, você precisa criar personal access tokens que possam acessar as organizações de origem e de destino e definir os personal access tokens como variáveis de ambiente.

Crie e registre um personal access token (classic) que será autenticado para a organização de destino no GitHub Enterprise Cloud, verificando se o token atende a todos os requisitos. Para obter mais informações, confira "Gerenciando o acesso para uma migração entre produtos GitHub".
Crie e registre um personal access token que será autenticado para a organização de origem, verificando se esse token também atende a todos os mesmos requisitos.
Defina variáveis de ambiente para o personal access tokens, substituindo TOKEN nos comandos abaixo pelos personal access tokens que você registrou acima. Use GH_PAT para a organização de destino e GH_SOURCE_PAT para a organização de origem.
- Se você estiver usando o Terminal, use o comando export.
  Shell
```
export GH_PAT="TOKEN"
export GH_SOURCE_PAT="TOKEN"
```
```
export GH_PAT="TOKEN"
export GH_SOURCE_PAT="TOKEN"
```
- Se você estiver usando o PowerShell, use o comando $env.
  Shell
```
$env:GH_PAT="TOKEN"
$env:GH_SOURCE_PAT="TOKEN"
```
```
$env:GH_PAT="TOKEN"
$env:GH_SOURCE_PAT="TOKEN"
```
Se você estiver migrando para o GitHub Enterprise Cloud com residência de dados, por questões de conveniência, defina uma variável de ambiente para a URL de API base da sua empresa. Por exemplo:
Shell
```
export TARGET_API_URL="https://api.octocorp.ghe.com"
```
```
export TARGET_API_URL="https://api.octocorp.ghe.com"
```
Você usará essa variável com a opção --target-api-url em comandos executados com a GitHub CLI.

Etapa 4: Gerar um script de migração

Caso você deseje migrar vários repositórios para o GitHub Enterprise Cloud ao mesmo tempo, use a GitHub CLI para gerar um script de migração. O script resultante conterá uma lista de comandos de migração, um por repositório.

Observação: a geração de um script produz um script do PowerShell. Se você estiver usando o Terminal, precisará gerar o script com a extensão de arquivo .ps1 e instalar o PowerShell para Mac ou Linux para executá-lo.

Caso você deseje migrar um repositório individual, vá para a próxima etapa.

Como gerar um script de migração

Para gerar um script de migração, execute o comando gh gei generate-script.

Shell

gh gei generate-script --github-source-org SOURCE --github-target-org DESTINATION --output FILENAME

gh gei generate-script --github-source-org SOURCE --github-target-org DESTINATION --output FILENAME

Se você baixou GEI como um binário autônomo em vez de como uma extensão para o GitHub CLI, será necessário atualizar o script gerado para executar o binário em vez de gh gei.

Espaços reservados

Substitua os espaços reservados no comando acima pelos valores a seguir.

Espaço reservado	Valor
SOURCE	Nome da organização de origem
DESTINATION	Nome da organização de destino
FILENAME	Um nome de arquivo para o script de migração resultante Se estiver usando o Terminal, use uma extensão de arquivo `.ps1`, pois o script gerado exige a execução do PowerShell. Você pode instalar o PowerShell para Mac ou Linux.

Argumentos adicionais

Argument	Descrição
`--target-api-url TARGET-API-URL`	Se você estiver migrando para o GHE.com, adicione `--target-api-url TARGET-API-URL`, em que TARGET-API-URL é a URL da API base para o subdomínio da sua empresa. Por exemplo: `https://api.octocorp.ghe.com`.
`--download-migration-logs`	Baixe o log de migração de cada repositório migrado. Para obter mais informações sobre os logs de migração, confira "Como acessar os logs de migração do GitHub Enterprise Importer".

Como revisar o script de migração

Depois de gerar o script, analise o arquivo e, opcionalmente, edite o script.

Se houver repositórios que você não deseja migrar, exclua ou remova os comentários das linhas correspondentes.
Caso você deseje que algum repositório tenha um nome diferente na organização de destino, atualize o valor do sinalizador --target-repo correspondente.
Se você quiser alterar a visibilidade do novo repositório, atualize o valor do sinalizador --target-repo-visibility correspondente. Por padrão, o script define a mesma visibilidade que o repositório de origem.

Se o repositório tiver mais de 10 GB de dados de versões, as versões não poderão ser migradas. Use o sinalizador --skip-releases para migrar o repositório sem versões.

Se você baixou GEI como um binário autônomo em vez de como uma extensão para o GitHub CLI, será necessário atualizar o script gerado para executar o binário em vez de gh gei.

Etapa 5: Migrar repositórios

Você pode migrar vários repositórios com um script de migração ou um repositório individual com o comando gh gei migrate-repo.

Migrar vários repositórios

Para migrar vários repositórios, execute o script gerado acima. Substitua FILENAME nos comandos abaixo pelo nome do arquivo que você forneceu ao gerar o script.

Se estiver usando o Terminal, use ./.
Shell
```
./FILENAME
```
```
./FILENAME
```
Se estiver usando o PowerShell, use .\.
Shell
```
.\FILENAME
```
```
.\FILENAME
```

Migrar um repositório individual

Para migrar um repositório individual, use o comando gh gei migrate-repo.

Shell

gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME

gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME

Espaços reservados

Substitua os espaços reservados no comando acima pelos valores a seguir.

Espaço reservado	Valor
SOURCE	Nome da organização de origem
CURRENT-NAME	O nome do repositório que você deseja migrar
DESTINATION	Nome da organização de destino
NEW-NAME	O nome que você deseja dar ao repositório migrado

Argumentos adicionais

Argument	Descrição
`--target-api-url TARGET-API-URL`	Se você estiver migrando para o GHE.com, adicione `--target-api-url TARGET-API-URL`, em que TARGET-API-URL é a URL da API base para o subdomínio da sua empresa. Por exemplo: `https://api.octocorp.ghe.com`.
`--skip-releases`	Se o repositório tiver mais de 10 GB de dados de versões, as versões não poderão ser migradas. Use o sinalizador `--skip-releases` para migrar o repositório sem versões.
`--target-repo-visibility TARGET-VISIBILITY`	Todos os repositórios são migrados com visibilidade privada por padrão. Para definir a visibilidade, você pode adicionar o sinalizador `--target-repo-visibility` especificando `private`, `public` ou `internal`. Se você estiver migrando para um empresa com usuários gerenciados, os repositórios públicos não estarão disponíveis.

Como anular a migração

Se você quiser cancelar uma migração, use o comando abort-migration, substituindo MIGRATION-ID pelo ID retornado de migrate-repo.

Shell

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

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

Etapa 6: Validar a migração e verificar o log de erros

Quando a migração for concluída, recomendaremos analisar o log de migração. Para obter mais informações, confira "Como acessar os logs de migração do GitHub Enterprise Importer".

Recomendamos que você analise os repositórios migrados para uma verificação de integridade.

Como migrar repositórios do GitHub.com para o GitHub Enterprise Cloud

Tool navigation

Neste artigo

Sobre as migrações de repositório com o GitHub Enterprise Importer

Pré-requisitos

Etapa 0: Preparar-se para usar a API do GraphQL do GitHub

Etapa 1: Obter a `ownerId` do destino de migração

Consulta `GetOrgInfo`

Resposta `GetOrgInfo`

Etapa 2: Identificar a origem da migração

Mutação `createMigrationSource`

Resposta `createMigrationSource`

Etapa 3: Iniciar a migração do repositório

Mutação `startRepositoryMigration`

Etapa 4: Verificar o status da migração

Consulta `getMigration`

Etapa 5: Validar a migração e verificar o log de erros

Etapa 1: Instalar a GEI extension of the GitHub CLI

Etapa 2: Atualizar a GEI extension of the GitHub CLI

Etapa 3: Definir variáveis de ambiente

Etapa 4: Gerar um script de migração

Como gerar um script de migração

Espaços reservados

Argumentos adicionais

Como revisar o script de migração

Etapa 5: Migrar repositórios

Migrar vários repositórios

Migrar um repositório individual

Espaços reservados

Argumentos adicionais

Como anular a migração

Etapa 6: Validar a migração e verificar o log de erros