トラブルシューティング

GitLabに移行する際、以下のイシューが発生する可能性があります。

インポートされたリポジトリにブランチがない

インポートされたリポジトリにソースリポジトリのすべてのブランチが含まれていない場合:

1. 環境変数IMPORT_DEBUG=trueを設定します。
2. 別のグループ、サブグループ、またはプロジェクト名を使用してインポートを再試行します。
3. 一部のブランチがまだ見つからない場合は、importer.log（たとえば、jqを使用）を調べます。

例外: Error Importing repository - No such file or directory @ rb_sysopen - (filename)

このエラーは、リポジトリのソースコードのtar.gzファイルダウンロードをインポートしようとすると発生します。

インポートには、単なるリポジトリのダウンロードファイルではなく、GitLabエクスポートファイルが必要です。

長期化または失敗したインポートを診断する

ファイルベースのインポート（特にS3を使用するインポート）で長期の遅延やエラーが発生している場合は、次の方法で問題の根本原因を特定できる可能性があります。

• インポート手順の確認
• ログのレビュー
• 一般的なイシューの特定

インポート状態を確認する

インポート状態を確認します。

1. GitLab APIを使用して、影響を受けるプロジェクトのインポート状態を確認します。
2. 特にstatus値とimport_error値について、エラーメッセージまたは状態情報に対する応答をレビューします。
3. 応答のcorrelation_idに注意してください。これは、さらなるトラブルシューティングに不可欠です。

ログをレビューする

関連情報についてログを検索します。

GitLab Self-Managedインスタンスの場合:

1. Sidekiqログとexceptions_jsonログを確認します。
2. RepositoryImportWorkerおよびインポート状態の確認からの相関IDに関連するエントリを検索します。
3. job_status、interrupted_count、exceptionなどのフィールドを探します。

GitLab.comの場合（GitLabチームメンバーのみ）:

1. Kibanaを使用して、次のようなクエリでSidekiqログを検索します。

   ターゲット: pubsub-sidekiq-inf-gprd*

   json.class: "RepositoryImportWorker" AND json.correlation_id.keyword: "<CORRELATION_ID>"

   または

   json.class: "RepositoryImportWorker" AND json.meta.project: "<project.full_path>"

2. GitLab Self-Managedインスタンスについて言及されているのと同じフィールドを探します。

共通のイシューを特定する

ログのレビューで収集した情報を、次の一般的なイシューと照らし合わせてレビューします。

• 中断されたジョブ: 失敗を示す高いinterrupted_countまたはjob_statusが表示された場合、インポートジョブが複数回中断され、デッドキューに配置された可能性があります。
• S3接続: S3を使用するインポートの場合は、ログでS3関連のエラーメッセージを確認してください。
• 大規模リポジトリ: リポジトリが非常に大きい場合、インポートがタイムアウトになる可能性があります。この場合は、直接転送の使用を検討してください。