Problembehandlung bei der Migration mit GitHub Enterprise Importer

Informationen zu den Schritten zur Problembehandlung für GitHub Enterprise Importer

Wenn bei der Migration ein Fehler auftritt oder unerwartete Ergebnisse erzielt werden, führe die unten aufgeführten ersten Schritte zur Problembehandlung aus, mit denen in der Regel viele Probleme behoben werden können. Wenn diese ersten Schritte dein Problem nicht beheben, suche in den Protokollen für deine Migration nach Fehlermeldungen. Suche dann in diesem Artikel nach der Fehlermeldung, und probiere die Schritte zur Lösung aus.

Wenn Sie Ihr Problem nach dem Ausprobieren der Schritte zur Problembehandlung für die Fehlermeldung nicht beheben können, können Sie sich an wenden GitHub-Support.

Erste Schritte zur Problembehandlung

Bevor du weitere Untersuchungen durchführst, führe die folgenden Schritte zur Problembehandlung aus, mit denen in der Regel viele Problemen behoben werden können.

1. Stellen Sie sicher, dass Sie die neueste Version der GitHub CLI Erweiterung verwenden, die Sie zum Migrieren verwenden. Wenn nicht, upgrade auf die neueste Version.

2. Vergewissere dich, dass alle Zugriffsanforderungen erfüllt sind. Weitere Informationen findest du im entsprechenden Artikel für deinen Migrationspfad.

   • Verwalten des Zugriffs für eine Migration von Bitbucket Server
   • Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten

3. Versuche, die Migration erneut auszuführen. Einige Migrationsprobleme sind nur vorübergehend, sodass ein zweiter Versuch Abhilfe schaffen kann.

4. Versuche, eine Migration in einem anderen Repository mit ähnlichen Daten auszuführen. Auf diese Weise kannst du feststellen, ob das Problem nur dieses Repository betrifft oder ein umfassenderes Problem mit der Datenform vorliegt.

Wenn das Problem durch diese Schritte nicht behoben wird, überprüfe das Migrationsprotokoll auf Fehlermeldungen. Welches Protokoll du überprüfen musst, hängt davon ab, ob die Migration fehlerhaft oder erfolgreich war.

Problembehandlung bei fehlerhaften Migrationsvorgängen

Wenn Ihre Migration fehlschlägt, überprüfen Sie die ausführlichen Protokolleinträge, die von der GitHub CLI für jede Migration erstellt wurden. Die Protokolldatei wird im selben Verzeichnis gespeichert, in dem du die Migration ausgeführt hast.

Das Protokoll enthält eine Aufzeichnung der einzelnen Befehle, die Sie ausgegeben haben, sowie aller API-Anforderungen, die GitHub CLI in Reaktion darauf gemacht hat. Fehler und Fehlermeldungen stehen normalerweise am Ende des Protokolls.

• Die Migration konnte nicht ausgeführt werden.
• Die Ressource wird durch die SAML-Richtlinien der Organisation geschützt.
• Antwort 401 Unauthorized
• Antwort 404 Not Found
• Antwort Archive generation failed
• cipher name is not supported Fehler
• Subsystem 'sftp' could not be executed Fehler
• Source export archive... does not exist Fehler
• Repository rule violations found Fehler
• Your push would publish a private email address Fehler

Die Migration konnte nicht ausgeführt werden.

Wenn ein Fehler wie No access to createMigrationMutation oder Missing permissions angezeigt wird, verfügt dein persönliches Konto nicht über den erforderlichen Zugriff für die Migration. Stelle sicher, dass du entweder Besitzer*in der Organisation bist oder dir die Migrationsrolle zugewiesen wurde. Weitere Informationen zum Zuweisen der Migrationsrolle finden Sie unter Informationen zu GitHub Enterprise Importer.

Die Ressource wird durch die Durchsetzung von SAML seitens der Organisation geschützt.

Dieser Fehler weist darauf hin, dass ein personal access token-Element, das von Ihnen für die GitHub CLI bereitgestellt wurde, für die Verwendung mit SAML‑Single‑Sign‑On autorisiert werden muss. Weitere Informationen finden Sie unter Autorisieren eines persönlichen Zugriffstokens für die Verwendung mit Single Sign-On.

          `401 Unauthorized`-Antwort

Fehler, die einen 401-Statuscode enthalten, deuten in der Regel darauf hin, dass das personal access token-Element, das von Ihnen für die GitHub CLI bereitgestellt wurde, nicht die erforderlichen Berechtigungen hat. Überprüfen Sie die Bereiche der von Ihnen bereitgestellten personal access token. Weitere Informationen zu erforderlichen Bereichen findest du im entsprechenden Artikel für deinen Migrationspfad.

• Verwalten des Zugriffs für eine Migration von Bitbucket Server
• Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten

          `404 Not Found`-Antwort

Fehler, die den Statuscode 404 enthalten, weisen meist auf einen Tippfehler in einem deiner Befehle hin. Überprüfe das Migrationsprotokoll auf den genauen Befehl, den du eingegeben hast, und suche im Quellrepository, in der Organisation oder im Projekt nach Tippfehlern.

          `Archive generation failed`-Antwort

Wenn Sie eine Archive generation failed...-Antwort erhalten, wenn Sie von GitHub Enterprise Server migrieren, ist Ihr Repository wahrscheinlich zu groß. Weitere Informationen zu Grenzwerten für die Repositorygröße findest du unter Informationen zu Migrationen zwischen GitHub-Produkten.

Versuche zunächst, Releases von der Migration auszuschließen, indem du das Flag --skip-releases mit dem Befehl migrate-repo verwendest.

Wenn dies nicht funktioniert, empfehlen wir ein Upgrade auf GitHub Enterprise Server 3.8.0 oder höher. Wenn du kein Upgrade durchführen kannst, besteht eine andere Möglichkeit darin, deine Repositoryarchive mit ghe-migrator manuell zu generieren:

1. Generiere ein Migrationsarchiv für dein Repository. Du solltest nur jeweils ein Repository gleichzeitig exportieren. Anweisungen finden Sie unter Exportieren von Migrationsdaten aus Ihrem Unternehmen.
2. Lade dein Migrationsarchiv in den Blobspeicheranbieter deiner Wahl hoch.
3. Generieren Sie eine kurzlebige URL für Ihr Migrationsarchiv, auf das GitHub zugreifen kann, z. B. eine vorsignierte AWS S3-URL oder Azure Blob Storage SAS-URL.
4. Rufe den Befehl migrate-repo mit den Flags --git-archive-url und --metadata-archive-url auf, die auf die URL deines Archivs aus dem vorherigen Schritt festgelegt sind.

          `cipher name is not supported` Fehler

Wenn du bei einer Migration von Bitbucket Server eine Fehlermeldung wie cipher name aes256-ctr for openssh key file is not supported erhältst, verwendet dein privater SSH-Schlüssel ein nicht unterstütztes Verschlüsselungsverfahren. Weitere Informationen zu unterstützten Verschlüsselungsverfahren findest du unter Verwalten des Zugriffs für eine Migration von Bitbucket Server.

Führe den folgenden Befehl aus, um ein neues kompatibles SSH-Schlüsselpaar zu generieren:

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

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

Nachdem du ein neues SSH-Schlüsselpaar generiert hast, musst du den öffentlichen Schlüssel den authorized_keys der Bitbucket Server-Instanz hinzufügen, bevor du den Schlüssel verwenden kannst.

          `Subsystem 'sftp' could not be executed` Fehler

Wenn du bei einer Migration von Bitbucket Server eine Fehlermeldung wie Subsystem 'sftp' could not be executed erhältst, ist SFTP auf deinem Server nicht aktiviert, oder dein Benutzerkonto verfügt nicht über SFTP-Zugriff.

Bitte kontaktieren Sie Ihren Serveradministrator oder Ihre Serveradministratorin und bitten Sie sie, den SFTP-Zugriff für Ihr Benutzerkonto zu aktivieren.

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

Wenn Sie von Bitbucket Server migrieren und eine Fehlermeldung wie Source export archive (/var/atlassian/application-data/bitbucket/shared/migration/export/Bitbucket_export_1.tar) does not exist erhalten, sucht GitHub CLI das Migrationsarchiv an der falschen Stelle auf Ihrer Bitbucket Server-Instanz.

Um dieses Problem zu beheben, lege das --bbs-shared-home-Argument für gh bbs2gh migrate-repo für deine Bitbucket Server-Instanz oder das freigegebene Basisverzeichnis des Rechenzentrums fest. Das standardmäßig freigegebene Basisverzeichnis ist /var/atlassian/application-data/bitbucket/shared, aber deine Konfiguration kann anders sein.

Du kannst das gemeinsam genutzte Home-Verzeichnis in Bitbucket Server identifizieren.

1. Navigiere zum Verwaltungsbereich deiner Bitbucket Server-Instanz oder deines Rechenzentrums.
2. Klicken Sie in der Randleiste unter „System“ auf Storage.
3. Zeige unter „Freigegebenes Verzeichnis“ den Speicherort des freigegebenen Basisverzeichnisses deines Servers an.

Wenn du das Bitbucket-Rechenzentrum im Clustermodus mit mehreren Knoten ausführst, wird dein freigegebenes Verzeichnis von Clusterknoten geteilt und sollte auf jedem Knoten an demselben Speicherort eingebunden werden.

          `Repository rule violations found` Fehler

Wenn dir eine Repository rule violations found-Fehlermeldung wie z. B. GH013: Repository rule violations found for refs/heads/main angezeigt wird, liegt ein Konflikt zwischen den Daten im Ursprungsrepository und den Daten in den Regelsätzen vor, die in der Zielorganisation konfiguriert sind. Weitere Informationen finden Sie unter Informationen zu Regelsätzen.

Du kannst deine Regelsätze während der Migration vorübergehend deaktivieren oder den Umgehungsmodus oder die Umgehungsliste verwenden, um deine konfigurierten Regeln von der Migration auszuschließen. Weitere Informationen finden Sie unter Verwalten von Regelsätzen für Repositorys in deiner Organisation.

          `Your push would publish a private email address` Fehler

Wenn Sie den Fehler Git source migration failed mit GH007: Your push would publish a private email address erhalten, enthält die Git-Quelle, die Sie migrieren möchten, Commits, die von einer E-Mail-Adresse erstellt wurden, deren Push auf GitHub blockiert wurde. Weitere Informationen finden Sie unter Pushes über die Befehlszeile blockieren, die Deine private E-Mail-Adresse offenlegen in der GitHub Enterprise Cloud Dokumentation.

Um diesen Fehler zu beheben, kannst du entweder den Git-Verlauf neu schreiben, um die E-Mail-Adresse zu entfernen, oder die Einstellung „Befehlszeilen-Pushvorgänge blockieren, die meine E-Mail-Adresse verfügbar machen“ deaktivieren.

Verständnis von Warnungen im Migrationsprotokoll

Auch wenn deine Migration erfolgreich ist, solltest du das Migrationsprotokoll weiterhin auf Warnungen überprüfen.

Warnungen im Migrationsprotokoll verweisen auf bestimmte Elemente innerhalb des Repositorys, die nicht migriert werden konnten. Weitere Informationen finden Sie unter Zugriff auf die Migrationsprotokolle von GitHub Enterprise Importer.

• Warnung: „Zu große Repositorymetadaten für die Migration“
• Warnung: „Kommentar nicht im Diff“
• Warnung: „Überprüfung des Pull-Request-Reviews... konnte aufgrund des Fehlers REVIEW_THREAD_MISSING_END_COMMIT_OID nicht importiert werden“
• Team-Referenzen sind nach einer Organisationsmigration defekt

Warnung: „Zu große Repositorymetadaten für die Migration“

Wenn im Issue „Migrationsprotokoll“ oder in der GitHub CLI als Fehler zu große Repositorymetadaten angezeigt werden, überschreitet dein Repository die maximale Archivgröße von 10 GB. Dies wird häufig durch große Release-Assets verursacht. Versuche, Releases mit dem Flag --skip-releases für den Befehl migrate-repo von der Migration auszuschließen.

Warnung: „Kommentar nicht im Diff“

Wenn Sie von Azure DevOps migrieren, können Pullanforderungskommentare in Zeilen, die in der Pullanforderung nie geändert wurden, nicht zu GitHub migriert werden. Diese Warnung wird für jeden Kommentar angezeigt, der aus diesem Grund nicht migriert werden kann.

Die betroffenen Kommentare sind zwar nicht im migrierten Repository enthalten, aber diese Warnungen erfordern keine weiteren Aktionen.

Warnung: „Überprüfung des Pull-Request-Reviews... konnte aufgrund des Fehlers REVIEW_THREAD_MISSING_END_COMMIT_OID nicht importiert werden“

Diese Warnung tritt auf, wenn ein Pull-Request-Review nicht migriert werden konnte, da der Commit, an den die Überprüfung angefügt ist, nicht mehr vorhanden ist.

Dies geschieht in der Regel, wenn Commits mit einem erzwungenen Push entfernt wurden oder eine Verzweigung gelöscht wurde.

In diesem Fall gehen die Kommentare nicht verloren, sondern werden als Inline-Pull-Request-Kommentare migriert, um den Verlauf beizubehalten, anstatt als ein Request, der an einen bestimmten Commit angehängt ist.

Die Überprüfung der Pullanforderung wird als Inline-Pullanforderungskommentar importiert.

Diese Warnungen deuten darauf hin, dass eine Pull-Request-Überprüfung nicht in ihrer ursprünglichen Form migriert werden konnte, sondern stattdessen als Inline-Kommentare innerhalb des Pull Requests:

• INVALID_REVIEW_THREAD
• LINE_NOT_FOUND_IN_DIFF
• REVIEW_THREAD_MISSING_BODY

Nach einer Migration der Organisation sind Teamreferenzen fehlerhaft.

Verweise auf Teams, z. B. @octo-org/octo-team, werden im Rahmen einer Organisationsmigration nicht aktualisiert. Dies kann zu Problemen in der Zielorganisation führen, da z. B. CODEOWNERS-Dateien nicht wie erwartet funktionieren.

Du kannst diese Verweise entweder nach der Migration aktualisieren, oder du kannst die Teamnamen beibehalten, indem du die Quellorganisation umbenennst und so den ursprünglichen Namen für deine Zielorganisation verwenden kannst.

Wenn deine Quellorganisation beispielsweise @octo-org heißt und deine CODEOWNERS-Datei einen Verweis auf das Team @octo-org/octo-team enthält, kannst du die Quellorganisation vor der Migration in @octo-org-temp umbenennen, sodass du @octo-org als Namen der neuen Organisation verwenden kannst. Das migrierte Team heißt dann @octo-org/octo-team, und die CODEOWNERS-Datei im migrierten Repository funktioniert wie erwartet.

Gesperrte Repositorys

Nach einer Migration stellst du möglicherweise fest, dass deine Quell- oder Zielrepositorys gesperrt sind, wodurch der Zugriff auf den Code des Repositorys und alle zugehörigen Ressourcen wie Issues und Pull Requests deaktiviert wird. Weitere Informationen zu gesperrten Repositorys findest du unter Informationen zu gesperrten Repositorys.

Der Prozess zum Entsperren eines Repositorys hängt vom Produkt ab GitHub , in dem das Repository gespeichert ist.

• Wenn sich das gesperrte Repository auf GitHub Enterprise Server befindet, kann ein Websiteadministrator das Repository über das Dashboard des Websiteadministrators entsperren. Weitere Informationen finden Sie unter Sperren eines Repositorys.
• Wenn das gesperrte Repository auf GitHub.com ist, können Sie Ihrer Websiteadministratoren kontaktieren, um das Repository zu entsperren.

Kontaktieren GitHub-Support

Wenn Sie Ihr Problem nach den oben genannten Schritten zur Fehlerbehebung weiterhin nicht lösen können, können Sie den GitHub-Support über das GitHub-Supportportal kontaktieren.