Skip to main content
Publicamos atualizações frequentes em nossa documentação, e a tradução desta página ainda pode estar em andamento. Para obter as informações mais atualizadas, acesse a documentação em inglês.
All products
Migrações

Como migrar repositórios do GitHub Enterprise Server para o GitHub Enterprise Cloud

Neste artigo

Você pode migrar repositórios do GitHub Enterprise Server para o GitHub Enterprise Cloud usando a GitHub CLI ou a API.

Observação: atualmente, o GitHub Enterprise Importer está em versão beta pública e sujeito a alterações.

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

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.

Se você optar por usar a API, precisará escrever seus scripts ou usar um cliente HTTP como o Insomnia. Saiba mais sobre como começar a usar as APIs do GitHub em "Introdução à API REST" e "Realizar chamadas com o GraphQL".

Para migrar seus repositórios do GitHub Enterprise Server para o GitHub Enterprise Cloud com as APIs, você vai:

  1. Criar um personal access token para a organização de origem e de destino
  2. Buscar a ownerId da organização de destino no GitHub Enterprise Cloud
  3. Configurar uma origem de migração por meio da API do GraphQL do GitHub.com para identificar a origem da migração
  4. Para cada repositório que você deseja migrar, repita essas etapas.
    • Use a API REST do sua instância do GitHub Enterprise Server para gerar arquivos de migração para seu repositório
    • Carregue os arquivos de migração em um local em que eles possam ser acessados pelo GitHub.com
    • Inicie a migração usando a API do GraphQL do GitHub.com, transmitindo as URLs de arquivo
    • Verificar o status da migração por meio da API do GraphQL
    • Validar a migração e verificar o log de erros

To see instructions for using the API, use the tool switcher at the top of the page.

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

Pré-requisitos

  • Para garantir que você entendeu as limitações de suporte conhecidas do Importer, leia "Sobre o GitHub Enterprise Importer".
  • We strongly recommend that you perform a trial run of your migration and complete your production migration soon after. To learn more about trial run best practices, see "Como se preparar para executar uma migração com o GitHub Enterprise Importer."
  • 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.
  • Você precisa ser um proprietário da organização ou receber a função de migrador nas organizações de origem e de destino. Para obter mais informações, confira "Como conceder a função de migrador ao GitHub Enterprise Importer".
  • Se você usar o GitHub Enterprise Server 3.8 ou superior, precisará acessar o Console de Gerenciamento.

Etapa 1. Criar o personal access token

  1. 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 "Como gerenciar o acesso do GitHub Enterprise Importer".
  2. 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.

Etapa 2: Obter a ownerId da organização de destino

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 consultaDescrição
loginO 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 3: Configurar o armazenamento de blobs

Como muitas instâncias do GitHub Enterprise Server são protegidas por firewalls, para o GitHub Enterprise Server versões 3.8 ou superiores, usamos o armazenamento de blobs como um local intermediário para armazenar seus dados que o GitHub poderá acessar.

Primeiro, você precisa configurar o armazenamento de blobs com um provedor de nuvem com suporte e, depois, definir as configurações no Console de Gerenciamento do sua instância do GitHub Enterprise Server.

Observação: você só precisará configurar o armazenamento de blobs se usar o GitHub Enterprise Server versões 3.8 ou superiores. Se você usar o GitHub Enterprise Server versões 3.7 ou inferiores, vá para a "Etapa 4: Configurar uma origem de migração no GitHub Enterprise Cloud".

O armazenamento de blobs é necessário para migrar repositórios com metadados ou origem do Git grandes. Se você usar o GitHub Enterprise Server versões 3.7 ou inferiores, não poderá executar migrações em que as exportações de metadados ou de origem do Git excedam 2 GB. Para executar essas migrações, atualize para o GitHub Enterprise Server versões 3.8 ou superiores.

Como configurar o armazenamento de blobs com um provedor de nuvem compatível

A GitHub CLI dá suporte aos seguintes provedores de armazenamento de blobs:

  • AWS (Amazon Web Services) S3
  • Armazenamento do Blobs do Azure

Como configurar um bucket de armazenamento da AWS S3

Na AWS, configure um bucket da S3. Para obter mais informações, confira Como criar um bucket na documentação da AWS.

Você também precisará ter uma chave de acesso da AWS e uma chave secreta com acesso read-write ao bucket.

Observação: o GitHub Enterprise Importer não exclui o arquivo da AWS após a conclusão da migração. Para reduzir os custos de armazenamento, recomendamos configurar a exclusão automática do arquivo após um período. Para obter mais informações, confira Como definir a configuração do ciclo de vida em um bucket na documentação da AWS.

Como configurar uma conta do Armazenamento de Blobs do Azure

No Azure, crie uma conta de armazenamento e anote a cadeia de conexão. Para obter mais informações, confira Gerenciar chaves de acesso da conta de armazenamento no Microsoft Docs.

Observação: o GitHub Enterprise Importer não exclui o arquivo do Armazenamento de Blobs do Azure após a conclusão da migração. Para reduzir os custos de armazenamento, recomendamos configurar a exclusão automática do arquivo após um período. Para obter mais informações, confira Otimizar os custos gerenciando automaticamente o ciclo de vida dos dados no Microsoft Docs.

Como configurar o armazenamento de blobs no Console de Gerenciamento do sua instância do GitHub Enterprise Server

Depois de configurar um bucket de armazenamento da AWS S3 ou uma conta de armazenamento do Armazenamento de Blobs do Azure, configure o armazenamento de blobs no Console de Gerenciamento do sua instância do GitHub Enterprise Server. Para obter mais informações sobre o Console de Gerenciamento, confira "Como administrar sua instância no console de gerenciamento".

  1. Em uma conta administrativa no GitHub Enterprise Cloud, no canto superior direito de qualquer página, clique em .
  2. Se você ainda não estiver na página "Administração do site", no canto superior esquerdo, clique em Administração do site. 1. Na barra lateral " Administrador do site", clique em Console de Gerenciamento .
  3. Faça logon no Console de Gerenciamento.
  4. Na barra de navegação superior, clique em Configurações.
  5. Em Migrações, clique em Habilitar as Migrações do GitHub .
  6. Opcionalmente, para importar as configurações de armazenamento que você definiu para o GitHub Actions, selecione Copiar configurações do Armazenamento em Ações. Para obter mais informações, confira "Como habilitar o GitHub Actions com o Armazenamento de Blobs do Azure" e "Como habilitar o GitHub Actions com o armazenamento da Amazon S3".
  7. Se você não importar as configurações de armazenamento do GitHub Actions, selecione Armazenamento de Blobs do Azure ou Amazon S3 e preencha os detalhes necessários.
  8. Clique em Testar configurações de armazenamento.
  9. Clique em Salvar alterações.

Etapa 4: Configurar uma origem de migração no GitHub Enterprise Cloud

You can set up a migration source using the createMigrationSource query. You'll need to supply the ownerId, or organization ID, gathered from the GetOrgInfo query.

A origem de migração é a sua organização no GitHub Enterprise Server.

Mutação 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
    }
  }
}

Observação: use GITHUB_ARCHIVE para type.

Variável da consultaDescrição
nameUm nome para a origem da migração. Esse nome se destina à sua referência, ou seja, você pode usar qualquer cadeia de caracteres.
ownerIdA ID da sua organização no GitHub Enterprise Cloud.

Resposta createMigrationSource

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ",
        "name": "GHES Source",
        "url": "https://my-ghes-hostname.com",
        "type": "GITHUB_ARCHIVE"
      }
    }
  }
}

Neste exemplo, MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ é a ID de origem da migração, que usaremos em uma etapa posterior.

Etapa 5: Gerar arquivos de migração no sua instância do GitHub Enterprise Server

Você usará a API REST para iniciar duas "migrações" no GitHub Enterprise Server: uma para gerar um arquivo da origem Git do repositório e outra para gerar um arquivo dos metadados do repositório (como problemas e solicitações de pull).

Para gerar o arquivo de origem do Git, faça uma solicitação POST a https://HOSTNAME/api/v3/orgs/ORGANIZATION/migrations, substituindo HOSTNAME pelo nome do host do sua instância do GitHub Enterprise Server e ORGANIZATION pelo logon da sua organização.

No corpo, especifique o repositório individual que deseja migrar. A solicitação será parecida com esta:

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
}

Para gerar o arquivo de metadados, envie uma solicitação semelhante para a mesma URL com o seguinte corpo:

{
  "repositories": ["repository_to_migrate"],
  "exclude_git_data": true,
  "exclude_releases": false,
  "exclude_owner_projects": true
}

Cada uma dessas duas chamadas à API retornará uma resposta JSON, incluindo a ID da migração iniciada.

HTTP/1.1 201 Created

{
  "id": 123,
  // ...
}

Para obter mais informações, confira "Iniciar uma migração de organização" na documentação da API REST.

A geração dos arquivos pode demorar um pouco, dependendo do volume de dados. Verifique regularmente o status das migrações com a API "Obter um status de migração da organização" até que o state da migração mude para 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",
  // ...
}

Para obter mais informações, confira "Obter um status de migração da organização" na documentação da API REST.

Observação: se a migração passar para o estado failed em vez de para o estado exported, tente iniciar a migração novamente. Em caso de falhas repetidas na migração, recomendamos gerar os arquivos usando ghe-migrator em vez da API.

Siga as etapas descritas em "Como exportar dados de migração da sua empresa", adicionando apenas um repositório à migração. No final do processo, você terá um arquivo de migração individual com os metadados e a origem do Git e poderá ir para a etapa 6 deste artigo.

Depois que o state de uma migração passar para exported, busque a URL da migração usando a API "Baixar um arquivo de migração da organização".

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

A API retornará uma resposta 302 Found com um cabeçalho Location redirecionando você para a URL em que o arquivo para download está localizado. Baixe os dois arquivos: um para a origem do Git e o outro para os metadados.

Para obter mais informações, confira "Baixar um arquivo de migração da organização" na documentação da API REST.

Depois que as duas migrações forem concluídas e você baixar os arquivos, vá para a próxima etapa.

Etapa 6: Carregar os arquivos de migração

Para importar seus dados para o GitHub Enterprise Cloud, você precisa transmitir os dois arquivos para cada repositório (metadados e origem do Git) do computador para o GitHub.com usando a API do GraphQL.

Se estiver usando o GitHub Enterprise Server 3.7 ou inferior, primeiro, precisará gerar URLs para os arquivos acessíveis para o GitHub.com. A maioria dos clientes opta por carregar os arquivos no serviço de armazenamento de blobs de um provedor de nuvem, como a Amazon S3 ou o Armazenamento de Blobs do Azure e, em seguida, gerar uma URL de curta duração para cada um.

Se você estiver usando o GitHub Enterprise Server 3.8 ou superior, a instância vai carregar os arquivos e gerar as URLs para você. O cabeçalho Location da etapa anterior retornará a URL de curta duração.

Talvez seja necessário incluir os intervalos de IP do GitHub na lista de permitidos. Para obter mais informações, confira "Como gerenciar o acesso do GitHub Enterprise Importer".

Etapa 7: 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!,
  $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
    }
  }
}
Variável da consultaDescrição
sourceIdA origem de migração id retornou da mutação createMigrationSource.
ownerIdA ID da sua organização no GitHub Enterprise Cloud.
repositoryNameUm 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.
continueOnErrorConfiguraçã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.
githubPatO personal access token da sua organização de destino no GitHub Enterprise Cloud. Para ver os requisitos do personal access token, confira "Como gerenciar o acesso do GitHub Enterprise Importer".
accessTokenOs dados do personal access token da origem.
targetRepoVisibilityA 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
metadataArchiveUrlUma URL acessível para o GitHub Enterprise Cloud para o arquivo de metadados.
sourceRepositoryUrlA URL do repositório na instância do GitHub Enterprise Server. Isso é obrigatório, mas o GitHub Enterprise Cloud não se comunicará diretamente com a sua instância do GitHub Enterprise Server.

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

Etapa 8: 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 consultaDescrição
idA id da migração que a mutação startRepositoryMigration retornou.

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

To finish your migration, we recommend that you check the "Migration Log" issue. This issue is created on GitHub in the destination repository.

Screenshot of an issue with the title "Migration Log." The second comment in the issue includes logs for a migration.

Finally, we recommend that you review your migrated repositories for a soundness check.

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

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

    1. Instale o GEI extension.
    Shell
    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. To make sure you're using the latest version, update the extension.

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.

  1. 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 "Como gerenciar o acesso do GitHub Enterprise Importer".

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

    • Se você estiver usando o PowerShell, use o comando $env.

      Shell
      $env:GH_PAT="TOKEN"
$env:GH_SOURCE_PAT="TOKEN"

Etapa 4: Configurar o armazenamento de blobs

Como muitas instâncias do GitHub Enterprise Server são protegidas por firewalls, usamos o armazenamento de blobs como um local intermediário para armazenar seus dados que o GitHub poderá acessar.

Primeiro, você precisa configurar o armazenamento de blobs com um provedor de nuvem compatível. Em seguida, você precisa configurar suas credenciais para o provedor de armazenamento no Console de Gerenciamento ou na GitHub CLI.

Como configurar o armazenamento de blobs com um provedor de nuvem compatível

A GitHub CLI dá suporte aos seguintes provedores de armazenamento de blobs:

  • AWS (Amazon Web Services) S3
  • Armazenamento do Blobs do Azure

Como configurar um bucket de armazenamento da AWS S3

Na AWS, configure um bucket da S3. Para obter mais informações, confira Como criar um bucket na documentação da AWS.

Você também precisará ter uma chave de acesso da AWS e uma chave secreta com acesso read-write ao bucket.

Observação: o GitHub Enterprise Importer não exclui o arquivo da AWS após a conclusão da migração. Para reduzir os custos de armazenamento, recomendamos configurar a exclusão automática do arquivo após um período. Para obter mais informações, confira Como definir a configuração do ciclo de vida em um bucket na documentação da AWS.

Como configurar uma conta de armazenamento do Armazenamento de Blobs do Azure

No Azure, crie uma conta de armazenamento e anote a cadeia de conexão. Para obter mais informações, confira Gerenciar chaves de acesso da conta de armazenamento no Microsoft Docs.

Observação: o GitHub Enterprise Importer não exclui o arquivo do Armazenamento de Blobs do Azure após a conclusão da migração. Para reduzir os custos de armazenamento, recomendamos configurar a exclusão automática do arquivo após um período. Para obter mais informações, confira Otimizar os custos gerenciando automaticamente o ciclo de vida dos dados no Microsoft Docs.

Como configurar suas credenciais do armazenamento de blobs

Depois de configurar o armazenamento de blobs com um provedor de nuvem compatível, você precisa configurar suas credenciais para o provedor de armazenamento no GitHub:

  • Se você usar o GitHub Enterprise Server 3.8 ou superior, configure suas credenciais no Console de Gerenciamento.
  • Se você usar o GitHub Enterprise Server 3.7 ou inferior, configure as credenciais na GitHub CLI.

Como configurar o armazenamento de blobs no Console de Gerenciamento do sua instância do GitHub Enterprise Server

Observação: você só precisará configurar o armazenamento de blobs no Console de Gerenciamento se usar o GitHub Enterprise Server 3.8 ou superior. Se você usar a versão 3.7 ou inferior, configure suas credenciais na GitHub CLI.

Depois de configurar um bucket de armazenamento da AWS S3 ou uma conta de armazenamento do Armazenamento de Blobs do Azure, configure o armazenamento de blobs no Console de Gerenciamento do sua instância do GitHub Enterprise Server. Para obter mais informações sobre o Console de Gerenciamento, confira "Como administrar sua instância no console de gerenciamento".

  1. Em uma conta administrativa no GitHub Enterprise Cloud, no canto superior direito de qualquer página, clique em .
  2. Se você ainda não estiver na página "Administração do site", no canto superior esquerdo, clique em Administração do site. 1. Na barra lateral " Administrador do site", clique em Console de Gerenciamento .
  3. Faça logon no Console de Gerenciamento.
  4. Na barra de navegação superior, clique em Configurações.
  5. Em Migrações, clique em Habilitar as Migrações do GitHub .
  6. Opcionalmente, para importar as configurações de armazenamento que você definiu para o GitHub Actions, selecione Copiar configurações do Armazenamento em Ações. Para obter mais informações, confira "Como habilitar o GitHub Actions com o Armazenamento de Blobs do Azure" e "Como habilitar o GitHub Actions com o armazenamento da Amazon S3".
  7. Se você não importar as configurações de armazenamento do GitHub Actions, selecione Armazenamento de Blobs do Azure ou Amazon S3 e preencha os detalhes necessários.
  8. Clique em Testar configurações de armazenamento.
  9. Clique em Salvar alterações.

Como configurar suas credenciais do armazenamento de blobs na GitHub CLI

Observação: você só precisará configurar suas credenciais do armazenamento de blobs na GitHub CLI se usar o GitHub Enterprise Server 3.7 ou inferior. Se você usar a versão 3.8 ou superior, configure o armazenamento de blobs no Console de Gerenciamento.

Se você configurar suas credenciais do armazenamento de blobs na GitHub CLI, não poderá executar migrações em que as exportações de metadados ou de origem do Git excedam 2 GB. Para executar essas migrações, atualize para o GitHub Enterprise Server 3.8 ou superior.

Como configurar credenciais da AWS S3 na GitHub CLI

Quando estiver pronto para executar a migração, transmita o nome do bucket, a chave de acesso e a chave secreta para a GitHub CLI como argumentos ou transmita-os usando variáveis de ambiente chamadas AWS_BUCKET_NAME, AWS_ACCESS_KEY e AWS_SECRET_KEY.

Como configurar credenciais de conta do Armazenamento de Blobs do Azure na GitHub CLI

Quando estiver pronto para executar a migração, transmita a cadeia de conexão para a GitHub CLI como um argumento ou usando uma variável de ambiente chamada AZURE_STORAGE_CONNECTION_STRING.

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

Como gerar um script de migração

Você precisa seguir esta etapa em um computador que possa acessar a API para o sua instância do GitHub Enterprise Server. Se você puder acessar a instância no navegador, o computador terá o acesso correto.

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

Para o GitHub Enterprise Server 3.8 ou posterior ou se você estiver usando a versão 3.7 ou inferior com o Armazenamento de Blobs do Azure, use os seguintes sinalizadores:

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

Se você estiver usando o GitHub Enterprise Server 3.7 ou inferior com a AWS S3, use os seguintes sinalizadores:

Shell
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

Se o sua instância do GitHub Enterprise Server usar um certificado SSL autoassinado ou inválido, use o sinalizador --no-ssl-verify. Com esse sinalizador, a GitHub CLI vai ignorar a verificação do certificado SSL ao extrair os dados somente da instância. Todas as outras chamadas verificarão o SSL.

If you want the script to download the migration log for each migrated repository, add the --download-migration-logs flag. For more information about migration logs, see "Como acessar os logs de migração do GitHub Enterprise Importer."

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. GHES-API-URL | A URL para a API do sua instância do GitHub Enterprise Server, como https://myghes.com/api/v3 AWS-BUCKET-NAME | The bucket name for your AWS S3 bucket

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.

Observação: 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.

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

Quando você migra repositórios, a GEI extension of the GitHub CLI executa as seguintes etapas:

  1. Conecta-se ao sua instância do GitHub Enterprise Server e gera dois arquivos de migração por repositório, um para a origem do Git e outro para os metadados
  2. Carrega os arquivos de migração no provedor de armazenamento de blobs de sua escolha
  3. Inicia a migração no GitHub Enterprise Cloud, usando as URLs dos arquivos armazenados com o provedor de armazenamento de blobs
  4. Exclui o arquivo de migração

Migrar vários repositórios

Se você estiver migrando do GitHub Enterprise Server 3.7 ou anterior, antes de executar o script, defina variáveis de ambiente adicionais para se autenticar no provedor de armazenamento de blobs.

  • Para o Armazenamento de Blobs do Azure, defina AZURE_STORAGE_CONNECTION_STRING como a cadeia de conexão para sua conta de armazenamento do Azure.

    Only connection strings using storage account access keys are supported. Connection strings which use shared access signatures (SAS) are not supported. For more information about storage account access keys, see Manage storage account access keys in the Azure documentation.

  • Para a AWS S3, defina as variáveis de ambiente a seguir.

    • AWS_ACCESS_KEY: a chave de acesso para o bucket
    • AWS_SECRET_KEY: a chave secreta do bucket
    • AWS_REGION: a região da AWS em que o bucket está localizado
    • AWS_SESSION_TOKEN: o token de sessão, se você estiver usando credenciais temporárias da AWS (confira Como usar credenciais temporárias com recursos da AWS na documentação da AWS)

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
  • Se estiver usando o PowerShell, use .\.
    Shell
    .\FILENAME

Migrar um repositório individual

Você precisa seguir esta etapa em um computador que possa acessar a API para o sua instância do GitHub Enterprise Server. Se você puder acessar a instância no navegador, o computador terá o acesso correto.

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

Se você estiver usando o GitHub Enterprise Server 3.8 ou posterior, use os seguintes sinalizadores:

Shell
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

Se você estiver migrando do GitHub Enterprise Server 3.7 ou anterior e usando o Armazenamento de Blobs do Azure como o provedor de armazenamento de blobs, use os seguintes sinalizadores para se autenticar:

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

Se você estiver migrando do GitHub Enterprise Server 3.7 ou anterior e usando o Amazon S3 como o provedor de armazenamento de blobs, use os seguintes sinalizadores para se autenticar:

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

Se o sua instância do GitHub Enterprise Server usar um certificado SSL autoassinado ou inválido, use o sinalizador --no-ssl-verify. Com esse sinalizador, a GitHub CLI vai ignorar a verificação do certificado SSL ao extrair os dados somente da instância. Todas as outras chamadas verificarão o SSL.

Observação: 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.

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 GHES-API-URL | A URL para a API do sua instância do GitHub Enterprise Server, como https://myghes.com/api/v3 AZURE_STORAGE_CONNECTION_STRING | A cadeia de conexão da sua conta de armazenamento do Azure.

Coloque a cadeia de conexão entre aspas, que contém caracteres que provavelmente serão interpretados de outro modo pelo shell. AWS-BUCKET-NAME | The bucket name for your AWS S3 bucket

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

Após a conclusão da migração, recomendamos excluir os arquivos do contêiner de armazenamento. Se você pretende concluir migrações adicionais, exclua o arquivo colocado no seu contêiner de armazenamento pela ADO2GH extension. Quando terminar a migração, você poderá excluir todo o contêiner.