{"meta":{"title":"Résolution des problèmes liés à votre migration avec GitHub Enterprise Importer","intro":"Si votre migration échoue ou produit des résultats inattendus, vous pouvez essayer les étapes de résolution des problèmes courantes.","product":"Migrations","breadcrumbs":[{"href":"/fr/migrations","title":"Migrations"},{"href":"/fr/migrations/troubleshooting","title":"Résoudre les problèmes de migration"},{"href":"/fr/migrations/troubleshooting/troubleshooting-your-migration-with-github-enterprise-importer","title":"Résoudre les problèmes de migration"}],"documentType":"article"},"body":"# Résolution des problèmes liés à votre migration avec GitHub Enterprise Importer\n\nSi votre migration échoue ou produit des résultats inattendus, vous pouvez essayer les étapes de résolution des problèmes courantes.\n\n## À propos des étapes de résolution des problèmes pour GitHub Enterprise Importer\n\nSi 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.\n\nSi 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.\n\n## Premières étapes de résolution des problèmes\n\nAvant 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.\n\n1. 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.\n\n2. Veillez à répondre à toutes les conditions d’accès. Pour plus d’informations, consultez l’article approprié pour votre chemin de migration.\n\n   * [Gérer l’accès](/fr/migrations/ado/manage-access)\n   * [Gestion de l’accès pour une migration à partir de Bitbucket Server](/fr/migrations/using-github-enterprise-importer/migrating-from-bitbucket-server-to-github-enterprise-cloud/managing-access-for-a-migration-from-bitbucket-server)\n   * [Gestion de l’accès pour une migration entre des produits GitHub](/fr/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products)\n\n3. Essayez de réexécuter la migration. Certains problèmes de migration sont temporaires, et une deuxième tentative peut fonctionner.\n\n4. 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.\n\nSi 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.\n\n## Résolution des problèmes de migrations échouées\n\nSi 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.\n\nLe 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.\n\n* [Impossible d’exécuter la migration](#unable-to-run-migrations)\n* [La ressource est protégée par la mise en application de SAML dans l’organisation](#resource-is-protected-by-organization-saml-enforcement)\n* [Réponse `401 Unauthorized`](#401-unauthorized-response)\n* [Réponse `404 Not Found`](#404-not-found-response)\n* [Réponse `Archive generation failed`](#archive-generation-failed-response)\n* [\n  `cipher name is not supported` erreur](#cipher-name-is-not-supported-error)\n* [\n  `Subsystem 'sftp' could not be executed` erreur](#subsystem-sftp-could-not-be-executed-error)\n* [\n  `Source export archive... does not exist` erreur](#source-export-archive-does-not-exist-error)\n* [\n  `Repository rule violations found` erreur](#repository-rule-violations-found-error)\n* [\n  `Your push would publish a private email address` erreur](#your-push-would-publish-a-private-email-address-error)\n\n### Impossible d’exécuter la migration\n\nSi 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](/fr/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/about-github-enterprise-importer).\n\n> \\[!NOTE]\n> Si vous migrez entre des GitHub produits, vérifiez que vous êtes propriétaire de l’organisation ou que vous avez reçu le rôle de migration pour les organisations sources et cibles.\n\n### La ressource est protégée par la mise en application de SAML dans l’organisation\n\nCette 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](/fr/enterprise-cloud@latest/authentication/authenticating-with-single-sign-on/authorizing-a-personal-access-token-for-use-with-single-sign-on) ».\n\n### Réponse `401 Unauthorized`\n\nLes é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.\n\n* [Gérer l’accès](/fr/migrations/ado/manage-access)\n* [Gestion de l’accès pour une migration à partir de Bitbucket Server](/fr/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)\n* [Gestion de l’accès pour une migration entre des produits GitHub](/fr/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#required-scopes-for-personal-access-tokens)\n\n### Réponse `404 Not Found`\n\nLes é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.\n\n### Réponse `Archive generation failed`\n\nSi 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 [À propos des migrations entre les produits GitHub avec GitHub Enterprise Importer](/fr/migrations/using-github-enterprise-importer/migrating-between-github-products/about-migrations-between-github-products#data-that-is-migrated-from-github-enterprise-server).\n\nTout d’abord, essayez d’exclure les versions de la migration à l’aide de l’indicateur `--skip-releases` avec la commande `migrate-repo`.\n\nSi 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` :\n\n1. 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](/fr/enterprise-server@3.22/migrations/using-ghe-migrator/exporting-migration-data-from-github-enterprise-server) dans la GitHub Enterprise Server documentation.\n2. Chargez votre archive de migration sur le fournisseur de stockage de blobs de votre choix.\n3. 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.\n4. 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.\n\n### `cipher name is not supported` Erreur\n\nSi 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](/fr/migrations/using-github-enterprise-importer/migrating-from-bitbucket-server-to-github-enterprise-cloud/managing-access-for-a-migration-from-bitbucket-server#required-permissions-for-bitbucket-server).\n\nPour générer une nouvelle paire de clés SSH compatible, exécutez la commande suivante :\n\n```shell copy\nssh-keygen -t ed25519 -Z aes256-cbc -C \"your_email@example.com\"\n```\n\nAprè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.\n\n### `Subsystem 'sftp' could not be executed` Erreur\n\nSi 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.\n\nVous devez contacter votre administrateur de serveur et lui demander d’activer l’accès SFTP pour votre compte d’utilisateur.\n\n### `Source export archive... does not exist` Erreur\n\nSi 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.\n\nPour 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.\n\nVous pouvez identifier le répertoire de base partagé dans Bitbucket Server.\n\n1. Accédez à la zone Administration de votre instance Bitbucket Serveur ou de votre centre de données.\n2. Dans la barre latérale, sous Système, cliquez sur **Stockage**.\n3. Sous « Répertoire partagé », affichez l’emplacement du répertoire de base partagé de votre serveur.\n\nSi 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.\n\n### `Repository rule violations found` Erreur\n\nSi 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](/fr/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets) ».\n\nVous 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](/fr/enterprise-cloud@latest/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization) ».\n\n### `Your push would publish a private email address` Erreur\n\nSi 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](/fr/account-and-profile/how-tos/email-preferences/blocking-command-line-pushes-that-expose-your-personal-email-address).\n\nPour 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 ».\n\n## Comprendre les avertissements du journal de migration\n\nMême si la migration réussit, vous devez toujours consulter le journal de migration pour vérifier s’il y a des avertissements.\n\nLes 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](/fr/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/accessing-your-migration-logs-for-github-enterprise-importer) ».\n\n> \\[!NOTE]\n> Si le problème « Journal de migration » inclut « Migration terminée » en bas, le dépôt a été migré. Les messages d'erreur indiquent uniquement que des éléments spécifiques dans le référentiel, notamment un commentaire sur une demande de tirage, peuvent ne pas avoir été correctement migrés.\n\n* [Avertissement : « Les métadonnées du référentiel sont trop volumineuses pour être migrées »](#warning-repository-metadata-too-big-to-migrate)\n* [Avertissement : « Commentaire hors diff »](#warning-comment-not-in-diff)\n* [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)\n* [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)\n\n### Avertissement : « Les métadonnées du référentiel sont trop volumineuses pour être migrées »\n\nSi 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`.\n\n### Avertissement : « Commentaire hors diff »\n\nSi 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.\n\n> \\[!NOTE]\n> Seuls les commentaires sur les lignes qui n’ont pas été modifiées dans une pull request sont affectés par cette limitation. Les commentaires sur les lignes qui ont été modifiées dans une pull request sont migrés.\n\nVeuillez 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.\n\n### 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 »\n\nCet 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.\n\nCela se produit généralement lorsque les commits ont été supprimés avec un push forcé, ou qu’une branche a été supprimée.\n\nDans 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.\n\n### La révision de la demande de tirage est importée sous forme de commentaire intégré à la demande de tirage.\n\nCes 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 :\n\n* `INVALID_REVIEW_THREAD`\n* `LINE_NOT_FOUND_IN_DIFF`\n* `REVIEW_THREAD_MISSING_BODY`\n\n### Les liens d'équipe sont rompus après une migration d'organisation\n\nLes 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.\n\nVous 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.\n\nPar 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.\n\n## Dépôts verrouillés\n\nAprè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](/fr/migrations/overview/about-locked-repositories).\n\nLe processus de déverrouillage d’un référentiel dépend du GitHub produit où le référentiel est stocké.\n\n* 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](/fr/enterprise-server@3.22/admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/locking-a-repository) dans la GitHub Enterprise Server documentation.\n* Si le référentiel verrouillé est activé GitHub.com, vous pouvez contacter nous par le biais du portail  pour déverrouiller le référentiel.\n\n> \\[!NOTE]\n> Si votre migration a échoué, vos données n’ont pas toutes été migrées. Si vous choisissez de déverrouiller et d’utiliser le dépôt, des données seront perdues. La suppression du dépôt verrouillé et une nouvelle tentative de migration peuvent se révéler être une meilleure solution.\n\n## Contacter Support GitHub\n\nSi 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](https://support.github.com)."}