Remarque
Enterprise Live Migrations est préversion publique et sujet à changement.
Si votre migration rencontre un problème, vérifiez l’état de la migration avec elm migration status --migration-id MIGRATION-ID et passez en revue les informations d’erreur.
États et actions recommandées
| État | Sens | Action recommandée |
|---|---|---|
| Créée | La migration a été créée, mais pas encore démarrée | Exécutez elm migration start |
| En file d'attente | La migration attend le démarrage | Wait |
| Exportation | Les données sont exportées à partir de la source | Surveiller avec elm migration status |
| Traitement | Les données exportées sont importées dans la destination | Superviser avec elm migration status |
| Prêt pour le basculement | La migration initiale est terminée et prête pour le passage. | Quand vous êtes prêt, exécutez elm migration cutover-to-destination |
| Découpage | Le référentiel source est verrouillé et les modifications restantes sont appliquées à la destination | Moniteur; l’état passe à Terminé |
| Completed | La migration s’est terminée avec succès | Vérifier le référentiel de destination et récupérer des mannequins |
| Échec | La migration a rencontré un échec irrécupérable | Examiner l’erreur (voir ci-dessous) |
| suspendu | La migration est suspendue | Reprendre la migration |
| ** |
** terminée | La migration a été annulée | N/A |
| Détérioré | La destination est inaccessible | Vérifier la connectivité réseau entre l’appliance GitHub Enterprise Server et GHE.com (voir ci-dessous) |
L’état de la migration est « Échec »
Une migration entre dans l’état Échec lorsqu’une erreur irrécupérable l’empêche de continuer. Il s’agit d’une différence entre les ressources individuelles qui n’ont pas pu être importées ; une migration ayant échoué signifie que la migration elle-même ne peut pas continuer.
Pour enquêter, exécutez elm migration status --migration-id MIGRATION-ID et passez en revue les détails de l'erreur dans la réponse. Chaque échec inclut un ID de corrélation au format (Correlation ID for Support: UUID). Si vous contactez Support GitHub, fournissez cet ID afin que l’équipe du support technique puisse examiner.
Après avoir résolu le problème sous-jacent, abandonnez la migration ayant échoué avec elm migration cancel --migration-id MIGRATION-ID et démarrez une nouvelle migration.
L’état de la migration est « Détérioré »
Un état détérioré signifie que le service de migration sur l’appliance GitHub Enterprise Server ne peut pas atteindre l’entreprise de destination. La migration se poursuit côté source, mais l’état de destination est inconnu.
Vérifiez la connectivité réseau entre l’appliance GitHub Enterprise Server et votre sous-domaine, GHE.compuis réexécutez elm migration status --migration-id MIGRATION-ID . La réponse d’état inclut un horodatage pour le dernier contact réussi avec la destination, ce qui peut vous aider à évaluer la durée pendant laquelle le problème de connectivité s’est produit.
Certaines ressources n’ont pas pu être importées
Les ressources individuelles peuvent ne pas être importées sans provoquer l’échec de la migration globale. Vous pouvez voir le nombre de ressources ayant échoué dans la sortie de elm migration status --migration-id MIGRATION-ID.
Les ressources ayant échoué sont affichées uniquement après que toutes les nouvelles tentatives automatiques ont été épuisées, les échecs que vous voyez sont donc confirmés comme non résolus sans intervention. Passez en revue les détails de l’erreur dans la réponse d’état : chaque ressource ayant échoué dans le remplissage rétroactif ou les mises à jour en direct s'affichera "state": "failed".
Si le nombre et les types de ressources ayant échoué sont acceptables, vous pouvez procéder au basculement. Si ce n’est pas le cas, abandonnez la migration, résolvez le problème sous-jacent, puis démarrez une nouvelle migration.
Échec du basculement et verrouillage du référentiel source
En cas d’échec d’un basculement en cours de processus, le dépôt source peut rester verrouillé ou archivé. Cela empêche les développeurs d’envoyer (push) vers la source alors que la destination peut toujours être incomplète.
Pour déverrouiller le référentiel source, un administrateur de site doit le déverrouiller à partir du GitHub Enterprise ServerConsole de gestion.
Une fois la source déverrouillée, vous pouvez effectuer une nouvelle tentative de basculement à l'aide de elm migration cutover-to-destination --migration-id MIGRATION-ID, ou l'abandonner avec elm migration cancel --migration-id MIGRATION-ID et démarrer une nouvelle migration quand vous êtes prêt.
La migration doit être redémarrée en raison d’un "force push"
Si quelqu’un effectue un "force push" sur la branche principale du dépôt source pendant qu’une migration est en cours, la synchronisation Git entre la source et la destination est rompue. Les poussées forcées réécrivent l’historique des commits d’une manière qui ne peut pas être réconciliée de manière incrémentielle.
Dans ce cas, interrompez la migration avec elm migration cancel --migration-id MIGRATION-ID et démarrez une nouvelle migration. Avant de redémarrer, communiquez à votre équipe que les push forcés vers la branche par défaut ne sont pas autorisés pendant qu’une migration est active.
Le jeton d’accès a été rejeté
Si votre migration échoue avec une erreur d’authentification, vérifiez que :
- Les deux jetons source et de destination sont personal access tokens (classic). Les jetons granulaires ne sont pas pris en charge.
- Les jetons ont les étendues spécifiées dans Migration de votre référentiel avec Enterprise Live Migrations.
- Si l’organisation de destination applique l’authentification unique SAML, le jeton doit être autorisé pour l’authentification unique.
L’URL GHES source a été rejetée
Enterprise Live Migrations nécessite l’URL GitHub Enterprise Server pour utiliser HTTPS. Si l’URL est configurée avec HTTP, la migration échoue à la validation préliminaire.