Se a migração encontrar um problema, verifique o status da migração com gh elm migration status --migration-id MIGRATION-ID e revise as informações de erro.
Status e ações recomendadas
| Status | Meaning | Ação recomendada |
|---|---|---|
| Criado | A migração foi criada, mas ainda não foi iniciada | Execute gh elm migration start |
| Queued | A migração está aguardando o início | Wait |
| Exportadores | Os dados estão sendo exportados da origem | Monitorar com gh elm migration status |
| Em processamento | Os dados exportados estão sendo importados para o destino | Monitorar com gh elm migration status |
| Pronto para substituição | A migração inicial está concluída e a migração está pronta para substituição | Quando estiver pronto, execute gh elm migration cutover |
| Substituindo | O repositório de origem é arquivado e as alterações restantes estão sendo aplicadas ao destino | Monitor; o status fará a transição para Concluído |
| Completed | A migração foi concluída com êxito | Verifique o repositório de destino e recupere os modelos |
| Falhou | A migração encontrou uma falha irrecuperável | Investigar o erro (veja abaixo) |
| Pausado | A migração está pausada | Verifique o motivo da pausa e resolva (veja abaixo) |
| Terminado | A migração foi cancelada | N/A |
| Degradado | O destino é inacessível | Verificar a conectividade de rede entre o dispositivo GitHub Enterprise Server e GHE.com (veja abaixo) |
O status da migração é "Falha"
Uma migração entra no status com falha quando um erro irrecuperável o impede de continuar. Isso é diferente dos recursos individuais que não foram importados. Uma migração com falha significa que a migração em si não pode continuar.
Para investigar, execute gh elm migration status --migration-id MIGRATION-ID e examine os detalhes do erro na resposta. Cada falha inclui uma ID de correlação no formato (Correlation ID for Support: UUID). Se você entrar em contato Suporte do GitHub, forneça esta ID para que a equipe de suporte possa investigar.
Depois de resolver o problema subjacente, anule a migração falha com gh elm migration cancel --migration-id MIGRATION-ID e inicie uma nova migração.
O status da migração é "Pausado"
Uma migração entra no status pausado quando um problema requer sua intervenção antes que ele possa continuar. Execute gh elm migration status --migration-id MIGRATION-ID e verifique o motivo da pausa.
Motivos comuns de pausa:
- Expiração da credencial: Uma das personal access tokens (classic) expirou. Crie um novo token com os escopos necessários e atualize-o com
gh elm credential update. Em seguida, reinicie a migração. - Limitação de taxa: a migração esbarrou nos limites de taxa da API. Aguarde alguns minutos e reinicie.
Para reiniciar uma migração pausada depois de resolver o problema subjacente:
gh elm migration start --migration-id MIGRATION-ID
O status da migração é "Degradado"
Um status degradado significa que o serviço de migração no GitHub Enterprise Server dispositivo não pode alcançar a empresa de destino. A migração continua no lado da origem, mas o status de destino é desconhecido.
Verifique a conectividade de rede entre o GitHub Enterprise Server equipamento e o seu subdomínio de GHE.com, em seguida, execute gh elm migration status --migration-id MIGRATION-ID novamente. A resposta de status inclui um carimbo de data/hora do último contato bem-sucedido com o destino, ajudando a determinar há quanto tempo o problema de conectividade está ocorrendo.
Migração presa em "Exportando"
Se a migração permanecer no status de Exportação sem nenhuma alteração de progresso por 30 minutos ou mais, o exportador poderá ficar preso.
-
Execute
gh elm migration status --migration-id MIGRATION-IDe observe se as contagens de recursos estão sendo alteradas. -
Se as contagens forem estáticas, verifique a conectividade de rede do dispositivo com o destino.
-
Examine os logs do GitHub Enterprise Server exportador no dispositivo (requer acesso de administrador SSH):
Shell journalctl -t elm-exporter-backfiller --since "1 hour ago" | tail -50 journalctl -t elm-exporter-sender --since "1 hour ago" | tail -50
journalctl -t elm-exporter-backfiller --since "1 hour ago" | tail -50 journalctl -t elm-exporter-sender --since "1 hour ago" | tail -50 -
Se a tarefa do exportador falhar, ela deverá ser recuperada automaticamente. Se isso não acontecer, entre em contato com Suporte do GitHub.
Sincronização do Git não concluída
Se gh elm migration status indicar que o push inicial do Git não foi concluído após um longo período, verifique os logs do sincronizador Git:
journalctl -t elm-exporter-git-syncer --since "2 hours ago"
journalctl -t elm-exporter-git-syncer --since "2 hours ago"
Pesquisar por:
connection refused: um problema de rede entre o GitHub Enterprise Server dispositivo e o destino. Verifique as regras de firewall e a resolução DNS.authentication failed: personal access token (classic) pode não ter os escopos necessários ou pode ter expirado.remote: error: o destino pode estar rejeitando o push. Entre em contato com Suporte do GitHub e informe os detalhes do erro.
Alguns recursos não foram importados
Os recursos individuais podem falhar ao importar sem causar falha na migração geral. Você pode ver uma contagem de recursos falhados na saída de gh elm migration status --migration-id MIGRATION-ID.
Os recursos com falha são mostrados somente depois que todas as novas tentativas automáticas tiverem sido esgotadas, portanto, todas as falhas que você vê são confirmadas como insolvíveis sem intervenção. Revise os detalhes do erro na resposta de status: cada recurso com falha em provisionamento ou atualizações ao vivo exibirá "state": "failed".
Se o número e os tipos de recursos com falha forem aceitáveis, você poderá continuar com a substituição. Caso contrário, anule a migração, resolva o problema subjacente e inicie uma nova migração.
A migração falhou e o repositório de origem não está disponível
Se uma transição falhar após o repositório de origem ter sido arquivado, o serviço ELM tentará desarquivar o repositório. Se isso falhar, um administrador de repositório poderá desarquivar o repositório. Consulte Arquivar repositórios.
Lembre-se de que desarquivar um repositório causará carga adicional na instância, pois todos os problemas e solicitações de pull no repositório serão reindexados no Elasticsearch.
Depois que o repositório de origem for desarquivado, você poderá repetir a substituição usando gh elm migration cutover --migration-id MIGRATION-ID ou abortar a migração com gh elm migration cancel --migration-id MIGRATION-ID e iniciar uma nova migração quando estiver pronto.
A migração deve ser reiniciada devido a um push forçado
Se alguém executar um push forçado para o ramo padrão do repositório de origem durante uma migração em andamento, a sincronização do Git entre o repositório de origem e o de destino é interrompida. Forçar pushes reescreve o histórico de commit de uma maneira que não pode ser reconciliada incrementalmente.
Se isso acontecer, aborte a migração com gh elm migration cancel --migration-id MIGRATION-ID e inicie uma nova migração. Antes de reiniciar, comunique à sua equipe que pushes forçados para a ramificação padrão não são permitidos enquanto uma migração está ativa.
O token de acesso à migração foi rejeitado
Se a migração falhar com um erro de autenticação, verifique se:
- Os tokens de origem e de destino são personal access tokens (classic). Fine-grained personal access tokens não há suporte.
- Se a organização de destino impor o logon único do SAML, o token deverá ser autorizado para SSO.
- Ambos os tokens têm os escopos especificados em Migrando seu repositório com Enterprise Live Migrations.
Se você tiver girado um token recentemente, a migração obterá novas credenciais automaticamente. Você não precisa executar ghe-config-apply ou reiniciar o serviço de migração.
GitHub CLI o token de acesso foi rejeitado
Enterprise Live Migrations usa dois conjuntos de credenciais. Esta seção se aplica aos tokens de operador criados na etapa 2 e armazenados localmente por gh elm configure.
O operador deve usar um personal access token (classic) para cada ponto de extremidade:
- O token do operador de origem deve ser criado em GitHub Enterprise Server.
- O token do operador de destino deve ser criado em GHE.com.
- Ambos os tokens têm os escopos especificados em Migrando seu repositório com Enterprise Live Migrations.
- O proprietário do token deve ser um administrador da empresa correspondente. Selecionar um escopo não concede acesso administrativo ao usuário.
- Fine-grained personal access tokens não há suporte.
Respostas comuns
| Resposta | Meaning | Solução |
|---|---|---|
401 Bad credentials | O endpoint não pôde autenticar o token. Os escopos de autorização ainda não foram avaliados. | Verifique se o token não expirou ou foi revogado, se ele foi completamente copiado e se os tokens de origem e de destino não foram trocados. Confirme se cada token foi criado no host em que ele está sendo usado. |
403 Forbidden | O token foi autenticado, mas seu usuário ou escopos não autorizam a operação. | Use um personal access token (classic) com admin:enterprise. Confirme se o proprietário do token é um administrador da empresa. Se o SSO do SAML se aplicar, autorize o token para SSO. |
Resource not accessible by personal access token | O tipo de token ou as permissões não têm suporte. Isso geralmente ocorre com um fine-grained personal access token. | Substitua-o por um personal access token (classic) que tenha admin:enterprise. |
404 Not Found | A solicitação pode estar usando a URL de API errada ou Enterprise Live Migrations pode não estar habilitada para a empresa de destino. | Para GHE.com, use a URL da API do tenant, como https:/, sem barra no final. Verifique também a URL da API de origem. Se ambas as URLs estiverem corretas, entre em contato com Suporte do GitHub para confirmar se Enterprise Live Migrations está habilitada. |
Validar os tokens de forma independente
Teste cada token no endpoint /user antes de usá-lo com Enterprise Live Migrations. Esses comandos imprimem cabeçalhos de resposta, mas descartam o corpo da resposta.
Para o token de origem (GitHub Enterprise Server):
curl --silent --show-error --output /dev/null --dump-header - \
--header "Authorization: Bearer $SOURCE_OPERATOR_TOKEN" \
"$SOURCE_API_URL/user"
Para o token de destino:
curl --silent --show-error --output /dev/null --dump-header - \
--header "Authorization: Bearer $TARGET_OPERATOR_TOKEN" \
"$TARGET_API_URL/user"
Cada solicitação deve retornar 200 OK. O X-OAuth-Scopes cabeçalho de resposta deve incluir admin:enterprise.
Se /user retornar 200 OK , mas um Enterprise Live Migrations comando retornar 401 Bad credentials, a CLI poderá ter um token ou URL diferente armazenado. Execute gh elm configure novamente e associe cuidadosamente cada token ao ponto de extremidade correspondente.
Os tokens de operador são armazenados localmente pela Enterprise Live Migrations CLI. Depois de girar um token de operador, execute gh elm configure novamente ou forneça as credenciais de substituição usando as opções de linha de comando apropriadas.
Isso difere dos tokens de serviço de migração configurados na etapa 4. As credenciais do serviço de migração atualizadas são coletadas automaticamente e não exigem ghe-config-apply nem uma reinicialização do serviço de migração.
Não inclua tokens de acesso em logs, capturas de tela, pacotes de suporte ou solicitações de suporte. Se o problema continuar, forneça a Suporte do GitHub o status HTTP, o hostname do endpoint, o ID de migração, a data e hora com fuso horário e qualquer ID de correlação, mas não o token.
A URL de origem do GHES foi rejeitada
Enterprise Live Migrations requer a GitHub Enterprise Server URL para usar HTTPS. Se a URL estiver configurada com HTTP, a migração falhará na validação de pré-vôo.
Coletando logs para suporte
Ao entrar em contato com Suporte do GitHub, os artefatos mais úteis são:
- Um pacote de suporte (preferencial): execute
ghe-support-bundle -uno dispositivo GitHub Enterprise Server. Isso captura automaticamente todos os Enterprise Live Migrations registros. - Saída de status de migração:
gh elm migration status --migration-id MIGRATION-ID - A ID de migração e o tempo aproximado de falha (com fuso horário)
- Todas as IDs de correlação de mensagens de erro
Se um pacote de suporte não for possível, você poderá coletar logs manualmente:
journalctl -t elm-exporter-migration-manager --since "24 hours ago" > migration-manager.log journalctl -t elm-exporter-backfiller --since "24 hours ago" > backfiller.log journalctl -t elm-exporter-sender --since "24 hours ago" > sender.log journalctl -t elm-exporter-git-syncer --since "24 hours ago" > git-syncer.log
journalctl -t elm-exporter-migration-manager --since "24 hours ago" > migration-manager.log
journalctl -t elm-exporter-backfiller --since "24 hours ago" > backfiller.log
journalctl -t elm-exporter-sender --since "24 hours ago" > sender.log
journalctl -t elm-exporter-git-syncer --since "24 hours ago" > git-syncer.log