Résolution des problèmes liés à votre migration avec GitHub Enterprise Importer

À propos des étapes de résolution des problèmes pour GitHub Enterprise Importer

Si votre migration échoue ou produit des résultats inattendus, essayez les premières étapes de résolution des problèmes ci-dessous, qui arrivent généralement à résoudre divers problèmes. Si ces premières étapes ne résolvent pas votre problème, recherchez les messages d’erreur dans les journaux de votre migration. Ensuite, recherchez le message d’erreur dans cet article et essayez les étapes de résolution.

Si vous ne parvenez pas à résoudre votre problème après avoir essayé les étapes de résolution des problèmes pour le message d’erreur, vous pouvez contacter Support GitHub.

Premières étapes de résolution des problèmes

Avant d’investiguer plus en profondeur, essayez ces étapes de résolution des problèmes qui permettent généralement de résoudre divers problèmes.

1. Vérifiez que vous utilisez la dernière version de l’extension GitHub CLI que vous utilisez pour migrer. Si ce n’est pas le cas, effectuez une mise à niveau vers la dernière version.

2. Veillez à répondre à toutes les conditions d’accès. Pour plus d’informations, consultez l’article approprié pour votre chemin de migration.

   •      [AUTOTITLE](/migrations/using-github-enterprise-importer/migrating-from-bitbucket-server-to-github-enterprise-cloud/managing-access-for-a-migration-from-bitbucket-server)
     

   •      [AUTOTITLE](/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products)
     

3. Essayez de réexécuter la migration. Certains problèmes de migration sont temporaires, et une deuxième tentative peut fonctionner.

4. Essayez d’exécuter une migration sur un autre dépôt avec des données similaires. Cela permet de déterminer si le problème est propre au référentiel ou s’il s’agit d’un problème de forme de données plus large.

Si ces étapes ne résolvent pas votre problème, examinez les journaux de migration pour y trouver des messages d'erreur. Le journal que vous devez consulter dépend de l’échec ou de la réussite de votre migration.

Résolution des problèmes de migrations échouées

Si votre migration échoue, passez en revue les entrées de journal détaillées produites par le GitHub CLI pour chaque migration. Le fichier journal est enregistré dans le même répertoire que celui où vous avez exécuté la migration.

Le journal contient un enregistrement de chaque commande que vous avez émise ainsi que de toutes les requêtes d’API émises par GitHub CLI en réponse. Les pannes et les messages d'erreur apparaissent normalement vers la fin du journal de logs.

•         [Impossible d’exécuter la migration](#unable-to-run-migrations)
  

•         [La ressource est protégée par la mise en application de SAML dans l’organisation](#resource-is-protected-by-organization-saml-enforcement)
  

•         [Réponse `401 Unauthorized`](#401-unauthorized-response)
  

•         [Réponse `404 Not Found`](#404-not-found-response)
  

•         [Réponse `Archive generation failed`](#archive-generation-failed-response)
  

•         [
          `cipher name is not supported` erreur](#cipher-name-is-not-supported-error)
  

•         [
          `Subsystem 'sftp' could not be executed` erreur](#subsystem-sftp-could-not-be-executed-error)
  

•         [
          `Source export archive... does not exist` erreur](#source-export-archive-does-not-exist-error)
  

•         [
          `Repository rule violations found` erreur](#repository-rule-violations-found-error)
  

•         [
          `Your push would publish a private email address` erreur](#your-push-would-publish-a-private-email-address-error)
  

Impossible d’exécuter la migration

Si vous voyez une erreur comme No access to createMigrationMutation ou Missing permissions, votre compte personnel ne dispose pas de l’accès requis pour exécuter la migration. Vérifiez que vous êtes propriétaire d’organisation ou que vous avez reçu le rôle de migrateur. Pour plus d’informations sur l’octroi du rôle de migrateur, consultez À propos de GitHub Enterprise Importer.

La ressource est protégée par la mise en application de SAML dans l’organisation

Cette erreur indique qu'un personal access token que vous avez fourni au GitHub CLI doit être autorisé pour utilisation avec l'authentification unique SAML. Pour plus d’informations, consultez « Autorisation d’un jeton d’accès personnel à utiliser avec l’authentification unique ».

Réponse 401 Unauthorized

Les échecs qui incluent un code d'état 401 indiquent généralement que le personal access token que vous avez fourni au GitHub CLI ne possède pas les étendues requises. Vérifiez les périmètres associés aux personal access tokens que vous avez fournis. Pour plus d’informations sur les étendues requises, consultez l’article approprié pour votre chemin de migration.

•      [AUTOTITLE](/migrations/using-github-enterprise-importer/migrating-from-bitbucket-server-to-github-enterprise-cloud/managing-access-for-a-migration-from-bitbucket-server#required-scopes-for-personal-access-tokens)
  

•      [AUTOTITLE](/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#required-scopes-for-personal-access-tokens)
  

Réponse 404 Not Found

Les échecs qui incluent un code d’état 404 indiquent généralement une faute de frappe dans l’une de vos commandes. Passez en revue le journal de migration pour connaître la commande exacte que vous avez entrée et recherchez les fautes de frappe dans le dépôt source, l’organisation ou le projet.

Réponse Archive generation failed

Si vous recevez une Archive generation failed... réponse lors de la migration depuis GitHub Enterprise Server, votre référentiel est probablement trop volumineux. Pour plus d’informations sur les tailles limites des référentiels, consultez Informations sur les migrations entre les produits GitHub.

Tout d’abord, essayez d’exclure les versions de la migration à l’aide de l’indicateur --skip-releases avec la commande migrate-repo.

Si cela ne fonctionne pas, nous vous recommandons de procéder à la mise à niveau vers GitHub Enterprise Server la version 3.8.0 ou ultérieure. Si vous ne parvenez pas à effectuer une mise à niveau, une autre option consiste à générer manuellement vos archives de dépôt à l’aide de ghe-migrator :

1. Générez une archive de migration pour votre dépôt. Vous ne devez exporter qu’un seul dépôt à la fois. Pour obtenir des instructions, consultez l’exportation des données de migration à partir de votre entreprise.
2. Chargez votre archive de migration sur le fournisseur de stockage de blobs de votre choix.
3. Générez une URL de courte durée pour votre archive de migration, accessible à GitHub, telle qu’une URL pré-signée AWS S3 ou une URL SAS Stockage Blob Azure.
4. Appelez la commande migrate-repo avec les indicateurs --git-archive-url et --metadata-archive-url définis sur l’URL de votre archive à l’étape précédente.

          `cipher name is not supported` erreur

Si vous effectuez une migration à partir de Bitbucket Server et que vous recevez une erreur comme cipher name aes256-ctr for openssh key file is not supported lors de l’exécution d’une migration, votre clé privée SSH utilise un chiffrement non pris en charge. Pour plus d’informations sur les chiffrements pris en charge, consultez Gestion de l’accès pour une migration à partir de Bitbucket Server.

Pour générer une nouvelle paire de clés SSH compatible, exécutez la commande suivante :

ssh-keygen -t ed25519 -Z aes256-cbc -C "your_email@example.com"

ssh-keygen -t ed25519 -Z aes256-cbc -C "your_email@example.com"

Après avoir généré une nouvelle paire de clés SSH, avant de pouvoir utiliser la clé, vous devez ajouter la clé publique aux authorized_keys de votre instance Bitbucket Server.

          `Subsystem 'sftp' could not be executed` erreur

Si vous migrez à partir de Bitbucket Server et que vous recevez une erreur de type Subsystem 'sftp' could not be executed, SFTP n’est pas activé sur votre serveur ou votre compte d’utilisateur n’a pas d’accès SFTP.

Vous devez contacter votre administrateur de serveur et lui demander d’activer l’accès SFTP pour votre compte d’utilisateur.

          `Source export archive... does not exist` erreur

Si vous migrez à partir de Bitbucket Server et que vous recevez une erreur comme Source export archive (/var/atlassian/application-data/bitbucket/shared/migration/export/Bitbucket_export_1.tar) does not exist, le GitHub CLI recherche votre archive de migration au mauvais endroit sur votre instance Bitbucket Server.

Pour résoudre ce problème, choisissez le répertoire de base partagé de Bitbucket Server ou de votre centre de données comme argument --bbs-shared-home pour gh bbs2gh migrate-repo. Le répertoire de base partagé par défaut est /var/atlassian/application-data/bitbucket/shared, mais votre configuration peut être différente.

Vous pouvez identifier le répertoire de base partagé dans Bitbucket Server.

1. Accédez à la zone Administration de votre instance Bitbucket Serveur ou de votre centre de données.
2. Dans la barre latérale, sous Système, cliquez sur Stockage.
3. Sous « Répertoire partagé », affichez l’emplacement du répertoire de base partagé de votre serveur.

Si vous exécutez Bitbucket Data Center en mode cluster avec plusieurs nœuds, votre répertoire partagé entre les nœuds du cluster doit être monté au même emplacement sur chaque nœud.

          `Repository rule violations found` erreur

Si vous recevez une erreur Repository rule violations found, telle que GH013: Repository rule violations found for refs/heads/main, les données du référentiel d’origine sont en conflit avec les ensembles de règles configurés sur l’organisation de destination. Pour plus d’informations, consultez « À propos des ensembles de règles ».

Vous pouvez temporairement désactiver vos ensembles de règles pendant votre migration, ou utiliser le mode de contournement ou la liste de contournement pour exempter votre migration des règles configurées. Pour plus d’informations, consultez « Gestion des ensembles de règles pour les dépôts de votre organisation ».

          `Your push would publish a private email address` erreur

Si une erreur Git source migration failed survient avec GH007: Your push would publish a private email address, cela signifie que la source Git que vous tentez de migrer contient des commits associés à une adresse e-mail que vous avez bloquée pour les opérations de push vers GitHub. Pour plus d’informations, consultez Blocage des poussées de ligne de commande qui exposent votre adresse e-mail personnelle dans la GitHub Enterprise Cloud documentation.

Pour résoudre cette erreur, vous pouvez réécrire l’historique Git pour supprimer l’adresse e-mail ou désactiver le paramètre « Bloquer les envois de ligne de commande qui exposent mon adresse e-mail ».

Comprendre les avertissements du journal de migration

Même si la migration réussit, vous devez toujours consulter le journal de migration pour vérifier s’il y a des avertissements.

Les avertissements dans le journal de migration indiquent les éléments spécifiques du référentiel qui n’ont pas pu être migrés. Pour plus d’informations, consultez « Accès à vos journaux de migration pour GitHub Enterprise Importer ».

•         [Avertissement : « Les métadonnées du référentiel sont trop volumineuses pour être migrées »](#warning-repository-metadata-too-big-to-migrate)
  

•         [Avertissement : « Commentaire hors diff »](#warning-comment-not-in-diff)
  

•         [Avertissement : « La révision de la requête de tirage...n’a pas pu être importée en raison de l’erreur REVIEW_THREAD_MISSING_END_COMMIT_OID »](#warning-pull-request-reviewcould-not-be-imported-due-to-review_thread_missing_end_commit_oid-error)
  

•         [Les références d’équipe sont désactivées après une migration de l’organisation](#team-references-are-broken-after-an-organization-migration)
  

Avertissement : « Les métadonnées du référentiel sont trop volumineuses pour être migrées »

Si vous voyez « Métadonnées du référentiel trop volumineuses pour migrer » dans le problème « Journal de migration » ou si GitHub CLIvotre référentiel dépasse la taille d’archivage maximale de 10 Go. Cela est souvent dû à des ressources de mise en production volumineuses. Essayez d’exclure les mises en production de la migration avec l’indicateur --skip-releases de la commande migrate-repo.

Avertissement : « Commentaire hors diff »

Si vous migrez à partir d'Azure DevOps, les commentaires de pull request sur les lignes qui n'ont jamais été modifiées dans la pull request ne peuvent pas être migrés vers GitHub. Vous verrez cet avertissement pour chaque commentaire qui ne peut pas être migré pour cette raison.

Veuillez noter que les commentaires affectés ne seront pas dans le dépôt migré, mais que ces avertissements ne demandent pas d’action supplémentaire de votre part.

Avertissement : « La révision de la requête de tirage...n’a pas pu être importée en raison de l’erreur REVIEW_THREAD_MISSING_END_COMMIT_OID »

Cet avertissement se produit lorsqu'un examen de la pull request n'a pas pu être migré, car le commit auquel l'examen est attaché n'est plus disponible.

Cela se produit généralement lorsque les commits ont été supprimés avec un push forcé, ou qu’une branche a été supprimée.

Dans ce cas, les commentaires ne sont pas perdus, mais sont migrés sous forme de commentaires en ligne de pull request pour préserver l'historique, plutôt que sous forme de révision attachée à une validation spécifique.

La révision de la demande de tirage est importée sous forme de commentaire intégré à la demande de tirage.

Ces avertissements signalent qu’une révision de demande de tirage n’a pas pu être migrée dans son format d’origine et a été convertie en commentaires intégrés à la demande de tirage :

• INVALID_REVIEW_THREAD
• LINE_NOT_FOUND_IN_DIFF
• REVIEW_THREAD_MISSING_BODY

Les liens d'équipe sont rompus après une migration d'organisation

Les références à des équipes, telles que @octo-org/octo-team, ne sont pas mises à jour dans le cadre d’une migration d’organisation. Cela risque d’entraîner des problèmes dans l’organisation de destination, comme par exemple les fichiers CODEOWNERS qui ne fonctionnent pas comme prévu.

Vous pouvez soit mettre à jour ces références après la migration, soit conserver vos noms d’équipe en renommant l’organisation source afin de pouvoir utiliser le nom d’origine de votre organisation de destination.

Par exemple, si votre organisation source s’appelle @octo-org et que votre fichier CODEOWNERS inclut une référence à l’équipe @octo-org/octo-team, vous pouvez renommer l’organisation source @octo-org-temp avant votre migration, ce qui vous permet d’utiliser @octo-org comme nom de la nouvelle organisation. Ensuite, l’équipe migrée sera appelée @octo-org/octo-team et le fichier CODEOWNERS dans le dépôt migré fonctionnera comme prévu.

Dépôts verrouillés

Après une migration, vous constaterez peut-être que vos dépôts source ou de destination sont verrouillés, ce qui désactive l’accès au code du dépôt et à toutes ses ressources, comme les problèmes et les demandes de tirage. Pour plus d’informations sur les référentiels verrouillés, consultez À propos des dépôts verrouillés.

Le processus de déverrouillage d’un référentiel dépend du GitHub produit où le référentiel est stocké.

• Si le référentiel verrouillé est activé GitHub Enterprise Server, un administrateur de site peut déverrouiller le référentiel à l’aide du tableau de bord administrateur du site. Pour plus d’informations, consultez Verrouillage d’un dépôt.
• Si le référentiel verrouillé est activé GitHub.com, vous pouvez contacter votre administrateur de site pour déverrouiller le référentiel.

Contacter Support GitHub

Si vous ne parvenez toujours pas à résoudre votre problème après avoir essayé les étapes de dépannage ci-dessus, vous pouvez contacter Support GitHub via Portail de support GitHub.