GitLabグループのマイグレーション
GitLabグループはマイグレーションできます：
- 自分で管理するGitLabからGitLab.comへ。
- GitLab.comから自主管理GitLabへ。
- セルフマネージドGitLabインスタンスから別のインスタンスへ。
- 同じGitLabインスタンス内のグループ間。
グループのマイグレーションには2つの方法があります：
- 直接転送（推奨）。
- エクスポートファイルのアップロード。
GitLab.com からセルフマネージド GitLab にマイグレーションする場合、管理者はセルフマネージド GitLab インスタンスにユーザーを作成することができます。
直接移行によるグループのマイグレーション（推奨）
- GitLab 13.7で
bulk_importというフラグを持つグループリソースに導入されました。デフォルトでは無効です。- GitLab.comでグループアイテムが有効になり、GitLab 14.3で自己管理。
- GitLab 14.4で
bulk_import_projectsというフラグを持つプロジェクトリソースに導入。デフォルトでは無効。- GitLab15.6でGitLab.comで有効に。
- 新しいアプリケーション設定
bulk_import_enabledがGitLab 15.8で導入されました。bulk_import機能フラグが削除されました。bulk_import_projectsGitLab 15.10で機能フラグが削除されました。
セルフマネジメントのGitLabでは、デフォルトではグループアイテムのマイグレーションは利用できません。この機能を表示するには、管理者がアプリケーション設定で有効にします。
直接転送によるグループのマイグレーションは、グループをある場所から別の場所にコピーします。できます：
- 一度に多くのグループをコピーします。
- GitLab UIで、トップレベルのグループをコピーします：
- 別のトップレベルグループ。
- 既存のトップレベルグループのサブグループ。
- GitLab.comを含む別のGitLabインスタンス。
- APIで、トップレベルのグループとサブグループをこれらの場所にコピーします。
- プロジェクト付きのグループ（ベータ版で本番環境では使用できません）またはプロジェクトなしのグループをコピーします。プロジェクトをグループと一緒にコピーできます：
- GitLab.comではデフォルトで。
すべてのグループやプロジェクトのリソースがコピーされるわけではありません。以下のコピーされたリソースのリストを参照してください：
直接転送によるマイグレーションに関するご意見は、フィードバックイシューにお寄せください。
グループをコピーする代わりにグループを移動したい場合、グループが同じGitLabインスタンスにあればグループを転送することができます。グループの転送はより速く、より完全なオプションです。
既知のイシュー
直接移籍によるマイグレーションに関する既知の問題については、エピック6629を参照してください。
マイグレーション期間の見積もり
直接移籍によるマイグレーション期間の見積もりは困難です。マイグレーション期間には以下の要因が影響します：
- 移行元と移行先の GitLab インスタンスで利用可能なハードウェアとデータベースのリソース。移行元と移行先のインスタンスのリソースが多いほど、マイグレーション期間が短くなります：
- ソースインスタンスはAPIリクエストを受け取り、エクスポートするエンティティを抽出してシリアライズします。
- デスティネーション・インスタンスはジョブを実行し、データベースにエンティティを作成します。
- エクスポートするデータの複雑さとサイズ。たとえば、それぞれ 1000 件のマージリクエストを持つ 2 つのプロジェクトをマイグレーションしたいとします。一方のプロジェクトのマージリクエストに添付ファイルやコメントなどの項目が多い場合、2つのプロジェクトの移行にかかる時間は大きく異なります。したがって、プロジェクトのマージリクエスト数は、プロジェクトのマイグレーションにかかる時間の予測にはなりません。
マイグレーションを確実に見積もる正確な公式はありません。しかし、プロジェクト関係をインポートする各パイプラインワーカーの平均所要時間は、プロジェクトのインポートにかかる時間の見当をつけるのに役立ちます：
| プロジェクトリソースの種類 | レコードのインポートにかかる平均時間（秒 |
|---|---|
| 空のプロジェクト | 2.4 |
| リポジトリ | 20 |
| プロジェクト属性 | 1.5 |
| メンバー | 0.2 |
| ラベル | 0.1 |
| マイルストーン | 0.07 |
| バッジ | 0.1 |
| イシュー | 0.1 |
| スニペット | 0.05 |
| スニペットリポジトリ | 0.5 |
| 役員一覧 | 0.1 |
| マージリクエスト | 1 |
| 外部プルリクエスト | 0.5 |
| 保護ブランチ | 0.1 |
| プロジェクトの特徴 | 0.3 |
| コンテナ有効期限ポリシー | 0.3 |
| サービスデスク設定 | 0.3 |
| リリース | 0.1 |
| CIパイプライン | 0.2 |
| コミットノート | 0.05 |
| Wiki | 10 |
| アップロードファイル | 0.5 |
| LFS オブジェクト | 0.5 |
| デザイン | 0.1 |
| Auto DevOps | 0.1 |
| パイプライン・スケジュール | 0.5 |
| リファレンス | 5 |
| プッシュルール | 0.1 |
大規模なプロジェクトをマイグレーションしていて、タイムアウトやマイグレーション期間に問題がある場合は、マイグレーション期間の短縮を参照してください。
限界
直接移行によるマイグレーションには、ハードコードされた制限が適用されます。
| リミット | 説明 |
|---|---|
| 6 | 移行先のGitLabインスタンスで1分間に許可されるマイグレーションの最大数/ユーザー。GitLab 15.9で導入。 |
| 5 GB | ソース・インスタンスからダウンロードできる最大リレーション・サイズ。 |
| 10 GB | 解凍されたアーカイブの最大サイズ。 |
| 210秒 | アーカイブファイルの解凍待ちの最大秒数。 |
| 50 MB | NDJSON行の最大長。 |
| 5分 | ソース・インスタンスの空のエクスポート・ステータスが発生するまでの最大秒数。 |
| 8時間 | マイグレーションがタイムアウトするまでの時間。 |
これらの API を使用して、リレーションシップの最大サイズ制限をテストできます：
いずれかのAPIがリレーションサイズの上限を超えるファイルを生成した場合、直接転送によるグループマイグレーションは失敗します。
可視性ルール
マイグレーション後：
- 非公開グループとプロジェクトは非公開のままです。
- 内部グループとプロジェクト：
- 内部グループとプロジェクト：内部グループにコピーされても、内部の可視性が制限されていない限り、内部グループのままです。その場合、グループとプロジェクトは非公開になります。
- 非公開グループにコピーされると非公開になります。
- 公開グループとプロジェクト：
ソースインスタンスで非公開ネットワークを使用してコンテンツを一般公開から隠した場合、デスティネーションインスタンスでも同様の設定を行うか、プライベートグループにインポートするようにしてください。
前提条件
GitLab16.0で導入され、GitLab15.11.1とGitLab15.10.5にバックポートされたDeveloperロールの代わりにMaintainerロールの要件。
ダイレクトトランスファーによるグループのマイグレーション：
- インスタンスまたはGitLab.com間のネットワーク接続がHTTPSに対応している必要があります。
- ファイアウォールが接続元と接続先のGitLabインスタンス間の接続をブロックしていないこと。
- 両方のGitLabインスタンスで、インスタンス管理者がアプリケーション設定で直接転送によるグループマイグレーションを有効にしている必要があります。
- 移行元のGitLabインスタンスはGitLab 14.0以降が稼働している必要があります。
- ソースGitLabインスタンスのパーソナルアクセストークンが必要です：
- GitLab 15.1 以降のソースインスタンスでは、パーソナルアクセストークンは
apiスコープを持っている必要があります。 - GitLab 15.0 以前のソースインスタンスでは、パーソナルアクセストークンは
apiとread_repositoryの両方のスコープを持つ必要があります。
- GitLab 15.1 以降のソースインスタンスでは、パーソナルアクセストークンは
- マイグレーション元のソースグループでオーナーロールを持っている必要があります。
- マイグレーション先のグループで、少なくともメンテナーのロールを持っている必要があります。
ユーザーアカウントの準備
GitLab がユーザーと貢献者を正しくマッピングするようにするため：
- 移行先のGitLabインスタンスで必要なユーザーを作成します。API を使ってユーザーを作成できるのは、セルフマネージドインスタンスだけです。GitLab.comまたはセルフマネージドGitLabインスタンスにマイグレーションするときは、以下のことができます：
- ユーザーを手動で作成します。
- 既存のSAML SSOプロバイダを設定または使用し、SCIMを通じてサポートされるSAML SSOグループのユーザー同期を活用します。GitLabのユーザーアカウント認証を、認証済みのEメールドメインでバイパスすることができます。
- ユーザーがソースGitLabインスタンス上で公開Eメールを持っていて、デスティネーションGitLabインスタンス上で確認されたEメールアドレスと一致することを確認してください。ほとんどのユーザーは、メールアドレスの確認を求めるメールを受け取ります。
- 移行先のインスタンスに既にユーザーが存在し、GitLab.comグループにSAML SSOを使用する場合は、すべてのユーザーがSAMLアイデンティティをGitLab.comアカウントにリンクする必要があります。
接続元の GitLab インスタンスに接続します。
インポートしたいグループを作成し、インポート元のGitLabインスタンスに接続します：
- どちらかを作成します：
- 新しいグループ。左サイドバーの上部にある「新規作成（{プラス}）」と「新規グループ」を選択します。次にグループのインポートを選択します。
- 新しいサブグループ。既存のグループのページで、どちらかを選択します：
- 新しいサブグループを選択します。
- 左サイドバーの上部にある「新規作成（{plus}）」と「新規サブグループ」を選択します。次に、既存グループのインポートリンクを選択します。
- GitLab 14.0以降が稼働しているGitLabインスタンスのURLを入力します。
- ソースGitLabインスタンスのパーソナルアクセストークンを入力します。
- Connect instanceを選択します。
インポートするグループとプロジェクトを選択します。
GitLab 15.8で導入された、プロジェクトあり/なしのグループをインポートするオプション。
ソースGitLabインスタンスへの作成者アクセスが許可されると、GitLabグループインポーターページにリダイレクトされます。ここでは、オーナーロールを持っている接続元インスタンスのトップレベルグループのリストを見ることができます。
- デフォルトでは、提案されたグループの名前空間はソースインスタンスに存在する名前と一致しますが、権限に基づいて、インポートを進める前にこれらの名前を編集することができます。
- インポートするグループの横で、いずれかを選択します：
- プロジェクトと一緒にインポートします。
- プロジェクトなしでインポート。
- ステータス欄には、各グループのインポートステータスが表示されます。ページを開いたままにしておくと、リアルタイムで更新されます。
- グループがインポートされたら、GitLabパスを選択してGitLab URLを開いてください。
グループのインポート履歴
ダイレクトトランスファーでマイグレーションしたすべてのグループは、グループインポート履歴ページに一覧表示されます。このリストには以下が含まれます：
- 移行元グループのパス。
- デスティネーショングループのパス。
- 各インポートの開始日。
- 各インポートのステータス。
- エラーが発生した場合は、エラーの詳細。
グループのインポート履歴を表示するには：
- GitLab にサインインします。
- 左サイドバーの上部にある「新規作成（{プラス}）」から「新規グループ」を選択します。
- グループのインポートを選択します。
- 右上の「History」を選択します。
- 特定のインポートにエラーがある場合は、Detailsを選択するとエラーが表示されます。
マイグレーションされたグループアイテム
マイグレーションされるグループアイテムは、移行先で使用しているGitLabのバージョンによって異なります。特定のグループアイテムがマイグレーションされるかどうかを確認するには：
-
すべてのエディションの
groups/stage.rbファイルと、](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/ee/bulk_imports/groups/stage.rb)移行先で使用しているバージョンの Enterprise Edition の[groups/stage.rbファイルを確認してください。例えば、バージョン15.9の場合： -
group/import_export.ymlファイルで、インストール先のバージョンに対応するグループを確認します。例えば、バージョン15.9の場合：https://gitlab.com/gitlab-org/gitlab/-/blob/15-9-stable-ee/lib/gitlab/import_export/group/import_export.yml.
その他のグループ項目はマイグレーションされません。
移行先のGitLabインスタンスにマイグレーションされるグループアイテムは以下の通りです：
| グループアイテム | 次で導入されました |
|---|---|
| バッジ | GitLab 13.11 |
| 役員一覧 | GitLab 13.7 |
| ボードリスト | GitLab 13.7 |
| エピック1 | GitLab 13.7 |
| グループラベル2 | GitLab 13.9 |
| イテレーション | GitLab 13.10 |
| イテレーションケイデンス | GitLab 15.4 |
| メンバー3 | GitLab 13.9 |
| グループのマイルストーン | GitLab 13.10 |
| 名前空間の設定 | GitLab 14.10 |
| リリースのマイルストーン | GitLab 15.0 |
| サブグループ | GitLab 13.7 |
| アップロードファイル | GitLab 13.7 |
- GitLab 15.4で導入されたエピックリソースの状態イベント、GitLab 13.12で導入されたラベルの関連付け、GitLab 13.7で導入された状態と状態ID、GitLab 14.0で導入されたシステムノートメタデータ。
- グループラベルは、インポート中に関連するラベルの優先順位を保持することはできません。これらのラベルは、関連するプロジェクトがインポート先のインスタンスにマイグレーションされた後、手動で優先順位を付け直す必要があります。
- グループメンバーは、ユーザーがインポートしたグループに関連付けられます：
- 既にインポート先のGitLabインスタンスに存在している場合。
- 送信元のGitLabインスタンスに、送信先のGitLabインスタンスで確認されたEメールと一致する公開Eメールがあること。
除外項目
マイグレーションから除外されるグループ項目があります：
- 機密情報が含まれている可能性があります：CI/CD変数、Webhook、デプロイトークン。
- サポートされていないもの: プッシュルール。
マイグレーションされたプロジェクトアイテム
マイグレーションするグループを選択する際にプロジェクトをマイグレーションすることを選択した場合、プロジェクトアイテムはプロジェクトと一緒にマイグレーションされます。
マイグレーションされるプロジェクトアイテムは、移行先で使用している GitLab のバージョンによって異なります。特定のプロジェクトアイテムがマイグレーションされるかどうかを確認するには：
-
すべてのエディションの
projects/stage.rbファイルと、](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/ee/bulk_imports/projects/stage.rb)移行先で使用しているバージョンの Enterprise Edition の[projects/stage.rbファイルを確認してください。例えば、バージョン 15.9 の場合： -
project/import_export.ymlファイルで、インストール先のバージョンに対応するプロジェクトを確認してください。例えば、バージョン15.9の場合:https://gitlab.com/gitlab-org/gitlab/-/blob/15-9-stable-ee/lib/gitlab/import_export/project/import_export.yml.
その他のプロジェクト項目はマイグレーションされません。
グループとともにプロジェクトをマイグレーションしないことを選択した場合、またはプロジェクトのマイグレーションを再試行したい場合は、APIを使用してプロジェクトのみのマイグレーションを開始できます。
移行先のGitLabインスタンスにマイグレーションされるプロジェクト項目は以下の通りです：
| プロジェクトアイテム | 次で導入されました |
|---|---|
| プロジェクト | GitLab 14.4 |
| Auto DevOps | GitLab 14.6 |
| バッジ | GitLab 14.6 |
| ブランチ（保護ブランチを含む） | GitLab 14.7 |
| CIパイプライン | GitLab 14.6 |
| コミットコメント | GitLab 15.10 |
| デザイン | GitLab 15.1 |
| イシュー | GitLab 14.4 |
| イシューボード | GitLab 14.4 |
| ラベル | GitLab 14.4 |
| LFS オブジェクト | GitLab 14.8 |
| メンバー | GitLab 14.8 |
| マージリクエスト | GitLab 14.5 |
| プッシュルール | GitLab 14.6 |
| マイルストーン | GitLab 14.5 |
| 外部からのプルリクエスト | GitLab 14.5 |
| パイプライン履歴 | GitLab 14.6 |
| パイプラインのスケジュール | GitLab 14.8 |
| プロジェクト機能 | GitLab 14.6 |
| リリース | GitLab 15.1 |
| 証拠のリリース | GitLab 15.1 |
| リポジトリ | GitLab 14.4 |
| スニペット | GitLab 14.6 |
| 設定 | GitLab 14.6 |
| アップロードファイル | GitLab 14.5 |
| Wiki | GitLab 14.6 |
イシュー関連項目
移行先のGitLabインスタンスにマイグレーションされるイシュー関連のプロジェクトアイテムには、以下のようなものがあります：
| イシュー関連プロジェクトアイテム | 次で導入されました |
|---|---|
| イシュー・イテレーション | GitLab 15.4 |
| リソースの状態イベントのイシュー | GitLab 15.4 |
| リソースのマイルストーンイベントの発行 | GitLab 15.4 |
| リソースのイテレーションイベントの発行 | GitLab 15.4 |
| マージリクエストの URL 参照 | GitLab 15.6 |
| タイムトラッキング | GitLab 14.4 |
マージリクエスト関連項目
移行先の GitLab インスタンスにマイグレーションされるマージリクエスト関連のプロジェクトアイテムには、以下のようなものがあります：
| マージリクエスト関連プロジェクトアイテム | 次で導入されました |
|---|---|
| 複数のマージリクエスト担当者 | GitLab 15.3 |
| マージリクエストレビューアー | GitLab 15.3 |
| マージリクエスト承認者 | GitLab 15.3 |
| マージリクエストリソースの状態イベント | GitLab 15.4 |
| マージリクエストリソースのマイルストーンイベント | GitLab 15.4 |
| イシューの URL 参照 | GitLab 15.6 |
| タイムトラッキング | GitLab 14.5 |
設定関連項目
移行先のGitLabインスタンスにマイグレーションされる設定関連のプロジェクト項目には、以下のようなものがあります：
| 設定関連のプロジェクトアイテム | 次で導入されました |
|---|---|
| アバター | GitLab 14.6 |
| コンテナの有効期限ポリシー | GitLab 14.6 |
| プロジェクトのプロパティ | GitLab 14.6 |
| サービスデスク | GitLab 14.6 |
除外項目
いくつかのプロジェクトアイテムはマイグレーションから除外されます：
- 機密情報が含まれている可能性があります：
- CI/CD 変数
- デプロイキー
- デプロイトークン
- パイプラインスケジュール変数
- パイプラインのトリガー
- Webhook
- はサポートされていません：
- エージェント
- コンテナレジストリ
- 環境
- フィーチャーフラグ
- インフラレジストリ
- パッケージ・レジストリ
- Pagesのドメイン
- リモートミラー
トラブルシューティング
Railsコンソールセッションでは、グループインポートの失敗やエラーメッセージを確認することができます：
# Get relevant import records
import = BulkImports::Entity.where(namespace_id: Group.id).map(&:bulk_import).last
# Alternative lookup by user
import = BulkImport.where(user_id: User.find(...)).last
# Get list of import entities. Each entity represents either a group or a project
entities = import.entities
# Get a list of entity failures
entities.map(&:failures).flatten
# Alternative failure lookup by status
entities.where(status: [-1]).pluck(:destination_name, :destination_namespace, :status)
また、APIエンドポイントを使用して、マイグレーションされたすべてのエンティティと、それに関連する失敗を確認することもできます。
古いインポート
GitLab 14.10で導入されました。
グループのマイグレーションをトラブルシューティングする際、インポートワーカーが実行に8時間以上かかったためにインポートが完了しないことがあります。この場合、BulkImport またはBulkImport::Entity のstatus は3 (timeout) になります：
# Get relevant import records
import = BulkImports::Entity.where(namespace_id: Group.id).map(&:bulk_import)
import.status #=> 3 means that the import timed out.
エラー：404 Group Not Found
数字のみで構成されたパス(例えば、5000)を持つグループをインポートしようとすると、GitLabはパスではなくIDでグループを見つけようとします。これはGitLab 15.4以前では404 Group Not Found エラーの原因となります。
これを解決するには、ソースグループのパスに数字以外の文字を含むように変更する必要があります：
-
GitLab UI：
- 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
- 設定] > [全般]を選択します。
- 詳細設定] を展開します。
- グループURLの変更]で、グループURLに数字以外の文字を含めるように変更します。
その他の404 エラー
グループをインポートする際、例えば他の404 エラーが発生することがあります：
"exception_message": "Unsuccessful response 404 from [FILTERED] Bo...",
"exception_class": "BulkImports::NetworkError",
このエラーは、_ソース・_インスタンスからの転送に問題があることを示しています。このエラーを解決するには、ソース・インスタンスで前提条件を満たしていることを確認します。
マイグレーション期間の短縮
1回の直接転送マイグレーションでは、移行先インスタンスで利用可能なワーカーの数に関係なく、1回のインポートにつき5つのエンティティ（グループまたはプロジェクト）が実行されます。とはいえ、移行先インスタンスのワーカー数を増やすと、各エンティティのインポートにかかる時間が短縮され、マイグレーションが高速化されます。
デスティネーションインスタンスのワーカー数を増やすと、ソースインスタンスのハードウェアリソースが飽和するまでのマイグレーション期間を短縮できます。バッチでのリレーションのエクスポートとインポート（エピック9036で提案）は、デスティネーションインスタンスに十分な利用可能なワーカーを持つことをさらに有用にします。
ソースインスタンス上のワーカーの数は、（実行中のインポートごとに）5つの同時実行エンティティを並行してエクスポートするのに十分でなければなりません。そうでないと、デスティネーションがエクスポートされたデータが利用可能になるのを待っている間に、遅延やタイムアウトが発生する可能性があります。
プロジェクトを異なるグループにディストリビューションすると、タイムアウトを回避できます。複数の大規模プロジェクトが同じグループにある場合は、次のことができます：
- 大規模プロジェクトを別のグループまたはサブグループに移動します。
- グループやサブグループごとにマイグレーションを開始します。
GitLab UIではトップレベルのグループしかマイグレーションできません。APIを使って、サブグループをマイグレーションすることもできます。
エクスポートファイルをアップロードしてグループをマイグレーション（非推奨）
前提条件：
- マイグレーションするグループのオーナーロール。
ファイルエクスポートを使用すると、次のことができます：
- 任意のグループをファイルにエクスポートし、そのファイルを別のGitLabインスタンスや同じインスタンス上の別の場所にアップロードします。
- GitLab UIまたはAPIを使用してください。
- グループを一つずつマイグレーションし、グループの各プロジェクトを一つずつエクスポート・インポートします。
管理者アクセストークンがインポートの実行に使用されている場合、GitLab はユーザー貢献を正しくマッピングします。セルフマネージドインスタンスから GitLab.com にインポートする場合、GitLab はユーザー貢献を正しくマッピングしません。セルフマネージドインスタンスからGitLab.comにインポートする際のユーザー貢献の正しいマッピングは、プロフェッショナルサービスチームの有償の関与によって維持することができます。
以下に注意してください。
- エクスポートは一時ディレクトリに保存され、特定のワーカーによって 24 時間ごとに削除されます。
- インポートしたプロジェクトからグループレベルのリレーションシップを維持するには、まずグループをエクスポートしてインポートし、目的のグループ構造にプロジェクトをインポートできるようにします。
- インポートされたグループには、親グループにインポートされない限り、
privateの可視レベルが与えられます。 - 親グループにインポートされた場合、サブグループは、特に制限がない限り、同じ可視性レベルを継承します。
- グループはCommunity EditionからEnterprise Editionにエクスポートできます。Enterprise Editionでは、Community Editionにはないグループデータも保持されます。グループをEnterprise EditionからCommunity Editionにエクスポートする場合、このデータが失われる可能性があります。詳しくは、EEからCEへのダウングレードをご覧ください。
互換性
GitLab 15.8 で、JSON 形式のプロジェクトファイルのエクスポートをサポートしなくなりました。
グループファイルのエクスポートは NDJSON フォーマットです。
GitLabのマイナーバージョン2つ前までのバージョンからエクスポートされたグループファイルをインポートすることができます。
使用例：
| 送信先バージョン | 対応バージョン |
|---|---|
| 13.0 | 13.0, 12.10, 12.9 |
| 13.1 | 13.1, 13.0, 12.10 |
エクスポート内容
グループ用のimport_export.yml ファイルは、ファイルエクスポートを使用してグループをマイグレーションする際にエクスポートおよびインポートされるアイテムの一覧です。移行先のGitLabインスタンスにインポートできるアイテムを確認するには、GitLabのバージョンのブランチでこのファイルを表示します。例えば、14-10-stable-ee ブランチのimport_export.yml。
エクスポートされるグループアイテムは以下の通りです：
- マイルストーン
- グループラベル_（ラベルの優先順位_なし）
- ボードとボードリスト
- バッジ
- サブグループ（前述のすべてのデータを含む）
- エピック
- イベント
- Wiki(GitLab 13.9 で導入)
- イテレーションケイデンス(15.4 で導入)
エクスポートされない項目は以下の通りです：
- プロジェクト
- ランナートークン
- SAML ディスカバリートークン
準備
- インポートしたグループのメンバー リストとそれぞれの権限を保持するには、これらのグループのユーザーをレビューします。必要なグループをインポートする前に、これらのユーザーが存在することを確認してください。
- ユーザーはインポート元のGitLabインスタンスで、インポート先のGitLabインスタンスで確認したプライマリEメールと一致する公開Eメールを設定する必要があります。ほとんどのユーザーは、Eメールアドレスの確認を求めるEメールを受け取ります。
グループのエクスポートを有効にします。
前提条件
- グループのオーナーロールを持っている必要があります。
グループのインポートとエクスポートを有効にするには、以下の手順に従います：
- 左のサイドバーで、Search を選択するか、次のページに進んでください。
- Admin Areaを選択します。
- 左サイドバーで、設定 > 一般を選択します。
- 表示とアクセス制御] を展開します。
- ソースのインポート] セクションで、必要なソースのチェックボックスを選択します。
グループのエクスポート
前提条件：
- グループのオーナーロールを持っている必要があります。
グループの内容をエクスポートするには：
- 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
- 設定] > [全般]を選択します。
- 詳細設定]セクションで、[エクスポートグループ]を選択します。
- エクスポートが生成されると、圧縮されたtarアーカイブにエクスポートされたコンテンツへのリンクが記載されたメールが届きます。
-
あるいは、UIからエクスポートをダウンロードすることもできます：
- グループの設定 > 一般ページに戻ります。
- 詳細」セクションで、「エクスポートをダウンロード」を選択します。また、Regenerate export（エクスポートの再生成）を選択して、新しいファイルを生成することもできます。
APIを使用してグループをエクスポートすることもできます。
グループのインポート
- 左サイドバーの上部にある「新規作成（{プラス}）」と「新規サブグループ」を選択します。
- 既存のグループのインポートリンクを選択します。
- グループ名を入力します。
- 関連するグループ URL を承認または変更します。
- ファイルを選択…を選択します。
- グループのエクスポートセクションでエクスポートしたファイルを選択します。
- インポートを開始するには、インポートを選択します。
オペレーションが完了すると、新しくインポートされたグループページが表示されます。
0 (無制限)です。管理者として、最大インポートファイルサイズを変更することができます。これを行うには、アプリケーション設定APIまたは管理エリアのmax_import_size オプションを使用します。GitLab 13.8でデフォルトが50MBから0に変更されました。レート制限
不正使用を避けるため、デフォルトではユーザーのレートが制限されています：
| リクエストタイプ | リミット |
|---|---|
| エクスポート | 毎分6グループ |
| エクスポートのダウンロード | 1グループにつき1ダウンロード/分 |
| インポート | 毎分6グループ |
グループとプロジェクトのインポートを自動化
ユーザー、グループ、プロジェクトのインポートAPIコールの自動化については、グループとプロジェクトのインポートの自動化を参照してください。