GitLab からの移行について
GitHub Enterprise Importerを使用して、GitLab から GitHub Enterprise Cloud (GitHub.com または GHE.com) にリポジトリを移行できます。
移行は、GL2GH extension of the GitHub CLI移行 API のクロスプラットフォーム コマンドライン ラッパーである GitHub を使用して実行されます。 リポジトリごとに、 GL2GH extension:
- GitLab プロジェクトを、Git リポジトリとプロジェクト メタデータ (問題、マージ要求、ラベル、マイルストーン、リリースなど) を含む
.tar.gzアーカイブにエクスポートします。 - コマンドを実行するコンピューターでアーカイブをローカルにステージングします。
- GitHubが読み取ることができる BLOB ストレージ (GitHub-owned blob storageまたは AWS S3 または Azure Blob Storage で所有しているストレージ アカウント) にアーカイブをアップロードします。
- アーカイブを移行先組織にインポートし、GitLab エンティティを同等のGitHubに変換します。
GitHubでエンタープライズ アカウントを作成する前に、企業がEnterprise Managed Usersを使用するかどうかを決定します。 これは、メンバーの認証方法と、ID とアクセスの管理方法に影響します。 「GitHub Enterprise Cloud におけるエンタープライズ種別の選択」を参照してください。
サポートされている GitLab のバージョン
GitLab.com と自己管理の両方の GitLab インスタンスから移行できます。
GitHub Enterprise Importer は、現在維持されている (有効期間外の) バージョンの GitLab をサポートしています。 保守されているバージョンの一覧については、GitLab ドキュメント のサポートステートメント を参照してください。 以前のバージョンはテストも評価もされていません。
移行されるデータ
データが GitLab エクスポート アーカイブに存在する場合、 GitHub Enterprise Importer は GitLab から GitHub Enterprise Cloud に次のデータを移行します。
- Git ソース (コミット履歴を含む) とリポジトリ Wiki
- コミットコメント
- 既定のブランチなど、クリーンにマップされるProject構成
- 問題と問題のコメント (問題の状態やマイルストーン イベントを含む)
- スレッド化されたディスカッションは、元のスレッドのコンテキストを含むフラット コメントとして移行されます
- マージ要求。次のような pull request に変換されます。
- コメント (差分データが存在する場合にのみレビュー コメントとして移行され、それ以外の場合はフラットな問題コメントとして移行されます。最新の差分のみがエクスポートに存在します)
- レビュー担当者と承認者
- マージ要求状態イベント
- マイルストーン
- タイムライン イベント
- 絵文字の反応
- アップロード (添付ファイル)
- アセットのリリースとリリース
- Project メンバー (マネキンとして移行)
移行されないデータ
次のデータは移行されません。
- Git LFS objects: ポインター ファイルは Git 履歴と共に移動しますが、バイナリ オブジェクトはフォローアップ タスクとして個別に移行先にプッシュする必要があります。 詳細については、「リポジトリを複製する」を参照してください。
- マージ トレイン、パイプライン ゲート、必要な承認、トピック、アバター、ミラーリングなどのリポジトリ ポリシー
- グループ設定とグループ メンバーシップ
- スニペット、発行ボード、時間追跡データ、および設計管理データ
- CI/CD パイプラインとパイプライン スケジュール (
.gitlab-ci.ymlに同等の自動 GitHub Actions はありません) - 脆弱性レポート
- Webhook、CI/CD 変数、ジョブ トレースと成果物、子パイプライン履歴、パイプライン トリガーなど、GitLab がエクスポートにまったく含まないデータ
移行されたデータに関する制限
移行できる GitHub Enterprise Importer には制限があります。 GitHubの制限に起因するものもあれば、GitHub Enterprise Importer自体の制限によるものです。
GitHub の制限事項
- 1 つの Git コミットに対する 2 GiB サイズの制限: Git リポジトリ内の 1 つのコミットは、2 GiB を超える可能性はありません。 いずれかのコミットが 2 GiB を超える場合は、コミットを 2 GiB 以下の小さなコミットに分割する必要があります。
- 1 回のプッシュで 2 GiB のサイズ制限: 1 回のプッシュは 2 GiB より大きくすることはできません。 大きいプッシュは、
pack exceeds maximum allowed sizeエラーで失敗します。 - Git 参照の 255 バイトの制限: 255 バイトを超える名前を持つ Git 参照 (一般に "ref" と呼ばれる) は 1 つもありません。 通常、これは、参照の長さ 255 文字を超えることはできませんが、絵文字などの ASCII 以外の文字が複数のバイトを消費する可能性があることを意味します。 いずれかの Git 参照が大きすぎる場合は、明確なエラー メッセージが返されます。
- 100 MiB ファイル サイズの制限: 移行が完了すると、Git リポジトリ内の 1 つのファイルは 100 MiB を超えなくなります。 リポジトリの移行中に、この制限は 400 MiB に引き上げられます。 Git LFSを使用して大きなファイルを格納することを検討してください。
GitHub Enterprise Importer の制限事項
- Git リポジトリの 40 GB のサイズ制限 (パブリック プレビュー): この制限はソース コードにのみ適用されます。 リポジトリ アーカイブが制限を超えているかどうかをチェックするには、git-sizer ツールを使用して出力の合計 BLOB サイズを確認します。 git-sizer ツールは、大きなファイル、BLOB サイズ、コミット サイズ、移行に影響する恐れがあるツリー数に関連する潜在的な問題を特定することにも役立ちます。
- **400 MiB ファイル サイズの制限:**GitHub Enterprise Importerを使用してリポジトリを移行する場合、Git リポジトリ内の 1 つのファイルが 400 MiB を超える可能性はありません。 大きなファイルを格納するために Git LFS を使用することを検討してください。
- **Git LFSオブジェクトは移行されません:**ImporterはGit LFSを使用するリポジトリを移行できますが、LFS オブジェクト自体は移行されません。 これらは、移行完了後にフォローアップ タスクとして移行先にプッシュできます。
- 遅延コード検索機能: リポジトリ移行後の検索インデックスの再作成には数時間かかることがあります。また、インデックスの再作成が完了するまで、コード検索で予期しない結果が返される可能性があります。
- Organization 用に構成されたルールセットによって移行が失敗する可能性がある: たとえば、コミット作成者のメール アドレスが
@monalisa.catで終わるように要求するルールを構成し、移行するリポジトリにこのルールに準拠していないコミットが含まれている場合、移行は失敗します。 - マネキンの内容が検索できない場合あり: マネキンは、インポートされた内容 (問題、pull request、コメントなど) が関連付けられているプレースホルダー ユーザーです。 割り当てられた問題など、マネキンに関連付けられている内容を検索しても、問題が見つからない可能性があります。 マネキンが回収されると、新しい所有者を介してコンテンツが見つかります。
GitLab の制限事項
- GitLab エクスポート アーカイブの 40 GB の制限: GitLab のプロジェクト エクスポート API では、GitLab.com で 40 GB を超えるアーカイブは生成されません。 GitHubソース サイズの制限とは異なり、これは、プロジェクト メタデータと Git ソースを含むエクスポート アーカイブ全体に適用されます。 この制限は GitLab によって設定され、セルフマネージド インスタンスでは異なる場合があります。