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.
Note
Se o repositório que você está migrando tiver conjuntos de regras que o repositório de recebimento não cumpre, a migração será bloqueada. Para ignorar esses conjuntos de regras e permitir a migração, você pode aplicar um bypass de conjunto de regras para todas as chaves de implantação na organização de destino.
Os conjuntos de regras de repositório podem ser definidos no nível da organização. Se o repositório de recebimento não corresponder a nenhum desses conjuntos de regras, você precisará usar o bypass de chave de implantação para cada um deles. Confira Criar conjuntos de regras para repositórios na sua organização.
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 do Azure DevOps para o GitHub Enterprise Cloud.
- 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 do Azure DevOps para o GitHub Enterprise Cloud.
- 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.
- Para a organização de destino no GitHub, você precisa ser um proprietário da organização ou ter a função de migrador. Para obter mais informações sobre a função de migrador, confira Gerenciando o acesso para uma migração do Azure DevOps.
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.
Sua fonte de migração é sua organização do ADO.
Mutação createMigrationSource
mutation createMigrationSource($name: String!, $ownerId: ID!) {
createMigrationSource(input: {name: $name, url: "https://dev.azure.com", ownerId: $ownerId, type: AZURE_DEVOPS}) {
migrationSource {
id
name
url
type
}
}
}
Note
Lembre-se de usar AZURE_DEVOPS 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": "Azure Devops Source",
"url": "https://dev.azure.com",
"type": "AZURE_DEVOPS"
}
}
}
}
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 create. |
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. |
target | 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. |
source | A URL do repositório de origem, usando o formato https:/. |
Para ver os requisitos do personal access token, confira Gerenciando o acesso para uma migração do Azure DevOps.
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 start 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.
Por fim, recomendamos que você revise os repositórios migrados para uma verificação de integridade.