GitHub Enterprise Importer を使用した移行のトラブルシューティング

移行が失敗した場合、または予期しない結果が発生した場合は、一般的なトラブルシューティング手順を試すことができます。

この記事で

          GitHub Enterprise Importerのトラブルシューティング手順について

移行が失敗した場合、または予期しない結果が発生した場合は、以下に示すトラブルシューティングの最初の手順を試してください。これにより、一般的にさまざまな問題が解決します。 これらの最初の手順で問題が解決しない場合は、移行のログにエラー メッセージがないか確認します。 次に、この記事のエラー メッセージを見つけて、解決の手順を試してください。

エラー メッセージのトラブルシューティング手順を試しても問題を解決できない場合は、 GitHub のサポートにお問い合わせください。

トラブルシューティングの最初の手順

さらに調査する前に、一般的にさまざまな問題を解決するこれらのトラブルシューティング手順を試してください。

  1. 移行に使用している GitHub CLI 拡張機能の最新バージョンを使用していることを確認します。 そうでない場合は、最新バージョンにアップグレードします。

  2. すべてのアクセス要件を満たしていることを確認します。 詳細については、移行パスに適した記事を参照してください。

  3. 移行をもう一度実行してみます。 一部の移行の問題は一時的なもので、2 回目を試してみるとうまくいくことがあります。

  4. 同様のデータがある別のリポジトリで移行を実行してみます。 これは、issue がリポジトリに固有であるか、より広範なデータ シェイプの問題を表しているかを判断するのに役立ちます。

これらの手順で問題が解決しない場合は、移行ログのエラー メッセージを確認します。 確認する必要があるログは、移行が失敗したか成功したかによって異なります。

失敗した移行のトラブルシューティング

移行に失敗した場合は、移行ごとに GitHub CLI によって生成された詳細ログ エントリを確認します。 このログ ファイルは、移行を実行したのと同じディレクトリに保存されます。

ログには、発行した各コマンドと、 GitHub CLI が応答して行ったすべての API 要求のレコードが含まれます。 失敗とエラー メッセージは、通常、ログの終わりの方に表示されます。

移行を実行できない

          `No access to createMigrationMutation` や `Missing permissions` のようなエラーが表示された場合、ご自身の個人アカウントに移行を実行するために必要なアクセス権がありません。 あなたが組織の所有者であるか、移行者の役割を与えられていることを確認してください。 移行者ロールの付与の詳細については、「[AUTOTITLE](/migrations/using-github-enterprise-importer/migrating-repositories-with-github-enterprise-importer)」を参照してください。

メモ

          GitHub製品間で移行する場合は、自分が組織の所有者であるか、移行元組織とターゲット組織の両方の移行者ロールが付与されていることを確認してください。

リソースが Organization の SAML 強制によって保護されている

このエラーは、personal access tokenに指定したGitHub CLIが SAML シングル サインオンでの使用を承認されている必要があることを示します。 詳しくは、「シングル サインオンに使用する個人用アクセス トークンの認可」をご覧ください。

          `401 Unauthorized` の応答

          `401`状態コードを含むエラーは、通常、personal access tokenに指定したGitHub CLIに必要なスコープがないことを示します。 指定した personal access tokenのスコープを確認します。 必要なスコープの詳細については、移行パスに適した記事を参照してください。


          `404 Not Found` の応答

          `404` 状態コードを含むエラーは、通常、いずれかのコマンドでの入力ミスを示します。 入力した正確なコマンドの移行ログを確認し、移行元のリポジトリ、Organization、またはプロジェクトに入力ミスがないか確認します。


          `Archive generation failed` の応答

          `Archive generation failed...`から移行するときにGitHub Enterprise Server応答を受け取った場合、リポジトリが大きすぎる可能性があります。 リポジトリのサイズ制限の詳細については、「[AUTOTITLE](/migrations/using-github-enterprise-importer/migrating-between-github-products/about-migrations-between-github-products#data-that-is-migrated-from-github-enterprise-server)」を参照してください。

まず、--skip-releases コマンドで migrate-repo フラグを使用して、移行からリリースを除外してみてください。

それでも問題が解決しない場合は、 GitHub Enterprise Server 3.8.0 以降にアップグレードすることをお勧めします。 アップグレードできない場合は、別のオプションとして、ghe-migrator を使用してリポジトリ アーカイブを手動で生成することもできます。

  1. リポジトリの移行アーカイブを生成します。 一度にエクスポートするリポジトリは 1 つだけにする必要があります。 手順については、「企業からの移行データのエクスポート」を参照してください GitHub Enterprise Serverのドキュメントを参照してください。
  2. 任意の BLOB ストレージ プロバイダーに移行アーカイブをアップロードします。
  3. AWS S3 の事前署名付き URL や Azure Blob Storage SAS URL など、GitHub からアクセスできる移行アーカイブの有効期間の短い URL を生成します。
  4.        `migrate-repo` と `--git-archive-url` の両方のフラグを前の手順のアーカイブの URL に設定して `--metadata-archive-url` コマンドを呼び出します。


          `cipher name is not supported` エラー

Bitbucket Server から移行していて、移行の実行時に cipher name aes256-ctr for openssh key file is not supported のようなエラーが表示された場合は、サポートされていない暗号が SSH 秘密キーで使用されています。 サポートされている暗号の詳細については、「Bitbucket サーバーからの移行のアクセスの管理」を参照してください。

互換性のある新しい SSH キーペアを生成するには、次のコマンドを実行します。

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

新しい SSH キーペアを生成した後、キーを使用する前に、公開キーを Bitbucket Server インスタンスの authorized_keys に追加する必要があります。

          `Subsystem 'sftp' could not be executed` エラー

Bitbucket Server から移行していて Subsystem 'sftp' could not be executed のようなエラーが発生する場合は、サーバー上で SFTP が有効になっていないか、ユーザー アカウントに SFTP アクセス権がありません。

サーバー管理者に連絡して、ユーザー アカウントでの SFTP アクセス権の有効化を依頼する必要があります。

          `Source export archive... does not exist` エラー

Bitbucket Server から移行するときに、 Source export archive (/var/atlassian/application-data/bitbucket/shared/migration/export/Bitbucket_export_1.tar) does not existなどのエラーが発生した場合、 GitHub CLI は、Bitbucket Server インスタンス上の間違った場所で移行アーカイブを探しています。

この問題を解決するには、--bbs-shared-home の gh bbs2gh migrate-repo 引数を、Bitbucket Server または Data Center の共有ホーム ディレクトリに設定します。 既定の共有ホーム ディレクトリは /var/atlassian/application-data/bitbucket/shared ですが、構成が異なる場合があります。

Bitbucket Server で共有ホーム ディレクトリを確認できます。

  1. Bitbucket Server または Data Center のインスタンスの管理領域に移動します。
  2. サイドバーの [システム] で、[ストレージ] をクリックします。
  3. [共有ディレクトリ] で、サーバーの共有ホーム ディレクトリの場所を確認します。

複数のメモを含むクラスター モードで Bitbucket Data Center を実行している場合、共有ディレクトリはクラスター ノード間で共有されており、各ノードの同じ場所にマウントする必要があります。

          `Repository rule violations found` エラー

          `Repository rule violations found` などの `GH013: Repository rule violations found for refs/heads/main` エラーが発生する場合は、移行元のリポジトリ内のデータが、移行先の組織で構成されているルールセットと競合しています。 詳しくは、「[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)」をご覧ください。

移行の間に一時的にルールセットを無効にするか、バイパス モードまたはバイパス リストを使って、構成されているルールから移行を除外することができます。 詳しくは、「組織内のリポジトリのルールセットを管理する」をご覧ください。

          `Your push would publish a private email address` エラー

          `Git source migration failed`で`GH007: Your push would publish a private email address` エラーが発生した場合、移行しようとしている Git ソースには、GitHubにプッシュされないようにブロックした電子メール アドレスによって作成されたコミットが含まれます。 詳細については、 [AUTOTITLE](/enterprise-cloud@latest/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/blocking-command-line-pushes-that-expose-your-personal-email-address) を参照してください。

このエラーを解決するには、Git 履歴を書き換えてメール アドレスを削除するか、[電子メールを公開するコマンド ライン プッシュをブロックする] 設定を無効にします。

移行ログの警告について

移行が成功した場合でも、移行ログを確認して警告をチェックする必要があります。

移行ログの警告は、移行できなかったリポジトリ内の特定の項目を指します。 詳しくは、「GitHub Enterprise Importer の移行ログへのアクセス」をご覧ください。

メモ

"Migration Log" issue の最後に "Migration completed" が含まれている場合、リポジトリは移行されました。 警告は、リポジトリ内の特定の項目 (pull request のコメントなど) が正しく移行されていない可能性があることのみを示します。

警告：「リポジトリ メタデータが大きすぎて移行できない」

"移行ログ" の問題または GitHub CLIに "リポジトリメタデータが大きすぎて移行できません" と表示された場合、リポジトリはアーカイブの最大サイズである 10 GB を超えています。 これは、多くの場合、大規模なリリース資産が原因で発生します。 --skip-releases コマンドで migrate-repo フラグを使用して、移行からリリースを除外してみてください。

警告： 「コメントが差分に含まれていない」

Azure DevOpsから移行する場合、pull request で変更されなかった行の pull request コメントを GitHub に移行することはできません。 この理由で移行できないすべてのコメントに対して、この警告が表示されます。

メモ

pull request で変更されなかった行のコメントのみが、この制限の影響を受けます。 pull request で変更された行のコメントは移行されます。

影響を受けるコメントは移行されたリポジトリには含まれませんが、これらの警告に対してユーザーによるそれ以上のアクションは必要ありません。

警告：「Pull Request Review...」は、REVIEW_THREAD_MISSING_END_COMMIT_OIDエラーが発生したため、インポートできませんでした。

この警告は、プルリクエストのレビューがアタッチされているコミットが存在しなくなり、レビューを移行できない場合に発生します。

これは通常、コミットがフォース プッシュで削除されたか、ブランチが削除された場合に発生します。

この場合、コメントは失われませんが、特定のコミットにアタッチされたレビューとしてではなく、履歴を保持するためのインライン pull requestコメントとして移行されます。

pull request レビューはインライン pull request コメントとしてインポートされます

次の警告は、pull request のレビューが元の形式で移行できなかったため、インラインの pull request コメントとして表示されることを示しています。

  • INVALID_REVIEW_THREAD
  • LINE_NOT_FOUND_IN_DIFF
  • REVIEW_THREAD_MISSING_BODY

Organization の移行後にチーム参照が壊れる

チームへの参照 (@octo-org/octo-team など) は、Organization の移行の一部として更新されません。 これにより、CODEOWNERS ファイルが期待どおりに動作しないなど、移行先の Organization で問題が発生する可能性があります。

移行後にこれらの参照を更新することも、移行元の Organization の名前を変更してチーム名を保持し、移行先 Organization の元の名前を使用することもできます。

たとえば、移行元 Organization が @octo-org で、CODEOWNERS ファイルにチーム @octo-org/octo-team への参照が含まれている場合は、移行前に移行元 Organization の名前を @octo-org-temp に変更し、新しい Organization の名前として @octo-org を使用できます。 そうすると、移行されたチームは @octo-org/octo-team と呼ばれ、移行されたリポジトリ内の CODEOWNERS ファイルは予期したとおりに動作します。

ロックされたリポジトリ

移行後、ソースまたは移行先のリポジトリがロックされ、リポジトリのコードとそのすべてのリソース (issue や pull request など) へのアクセスが無効になる場合があります。 ロックされたリポジトリの詳細については、「ロックされたリポジトリについて」を参照してください。

リポジトリのロックを解除するプロセスは、リポジトリが格納されている GitHub 製品によって異なります。

  • ロックされたリポジトリが GitHub Enterprise Serverされている場合、サイト管理者はサイト管理者ダッシュボードを使用してリポジトリのロックを解除できます。 詳細については、 リポジトリのロック GitHub Enterprise Serverのドキュメントを参照してください。
  • ロックされたリポジトリが GitHub.comされている場合は、 GitHub サポート ポータル に連絡してリポジトリのロックを解除できます。

メモ

移行が失敗した場合、必ずしもすべてのデータが移行されたとは限りません。 リポジトリのロックを解除して使用すると、データが失われます。 ロックされたリポジトリを削除して、移行を再試行することをお勧めします。

連絡する GitHub のサポート

上記のトラブルシューティング手順を試しても問題を解決できない場合は、GitHub のサポートからGitHub Support ポータルにお問い合わせください。