GitLabグループのマイグレーション

GitLabグループはマイグレーションできます:

  • 自分で管理するGitLabからGitLab.comへ。
  • GitLab.comから自主管理GitLabへ。
  • セルフマネージドGitLabインスタンスから別のインスタンスへ。
  • 同じGitLabインスタンス内のグループ間。

グループのマイグレーションには2つの方法があります:

  • 直接転送(推奨)。
  • エクスポートファイルのアップロード。

GitLab.com からセルフマネージド GitLab にマイグレーションする場合、管理者はセルフマネージド GitLab インスタンスにユーザーを作成することができます。

セルフマネジメントのGitLabでは、デフォルトではグループアイテムのマイグレーションは利用できません。この機能を表示するには、管理者がアプリケーション設定で有効にします。

直接転送によるグループのマイグレーションは、グループをある場所から別の場所にコピーします。できます:

  • 一度に多くのグループをコピーします。
  • GitLab UIで、トップレベルのグループをコピーします:
    • 別のトップレベルグループ。
    • 既存のトップレベルグループのサブグループ。
    • GitLab.comを含む別のGitLabインスタンス。
  • APIで、トップレベルのグループとサブグループをこれらの場所にコピーします。
  • プロジェクト付きのグループ(ベータ版で本番環境では使用できません)またはプロジェクトなしのグループをコピーします。プロジェクトをグループと一緒にコピーできます:
    • GitLab.comではデフォルトで。

すべてのグループやプロジェクトのリソースがコピーされるわけではありません。以下のコピーされたリソースのリストを参照してください:

caution
プロジェクトとグループのインポートはベータ版です。この機能は本番環境では使用できません。

直接転送によるマイグレーションに関するご意見は、フィードバックイシューにお寄せください。

グループをコピーする代わりにグループを移動したい場合、グループが同じ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
Wiki10
アップロードファイル0.5
LFS オブジェクト0.5
デザイン0.1
Auto DevOps0.1
パイプライン・スケジュール0.5
リファレンス5
プッシュルール0.1

大規模なプロジェクトをマイグレーションしていて、タイムアウトやマイグレーション期間に問題がある場合は、マイグレーション期間の短縮を参照してください。

限界

直接移行によるマイグレーションには、ハードコードされた制限が適用されます。

リミット説明
6移行先のGitLabインスタンスで1分間に許可されるマイグレーションの最大数/ユーザー。GitLab 15.9で導入
5 GBソース・インスタンスからダウンロードできる最大リレーション・サイズ。
10 GB解凍されたアーカイブの最大サイズ。
210秒アーカイブファイルの解凍待ちの最大秒数。
50 MBNDJSON行の最大長。
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 以前のソースインスタンスでは、パーソナルアクセストークンはapiread_repository の両方のスコープを持つ必要があります。
  • マイグレーション元のソースグループでオーナーロールを持っている必要があります。
  • マイグレーション先のグループで、少なくともメンテナーのロールを持っている必要があります。

ユーザーアカウントの準備

GitLab がユーザーと貢献者を正しくマッピングするようにするため:

  1. 移行先のGitLabインスタンスで必要なユーザーを作成します。API を使ってユーザーを作成できるのは、セルフマネージドインスタンスだけです。GitLab.comまたはセルフマネージドGitLabインスタンスにマイグレーションするときは、以下のことができます:
  2. ユーザーがソースGitLabインスタンス上で公開Eメールを持っていて、デスティネーションGitLabインスタンス上で確認されたEメールアドレスと一致することを確認してください。ほとんどのユーザーは、メールアドレスの確認を求めるメールを受け取ります。
  3. 移行先のインスタンスに既にユーザーが存在し、GitLab.comグループにSAML SSOを使用する場合は、すべてのユーザーがSAMLアイデンティティをGitLab.comアカウントにリンクする必要があります。

接続元の GitLab インスタンスに接続します。

インポートしたいグループを作成し、インポート元のGitLabインスタンスに接続します:

  1. どちらかを作成します:
    • 新しいグループ。左サイドバーの上部にある「新規作成({プラス})」と新規グループ」を選択します。次にグループのインポートを選択します。
    • 新しいサブグループ。既存のグループのページで、どちらかを選択します:
      • 新しいサブグループを選択します。
      • 左サイドバーの上部にある「新規作成({plus})」と新規サブグループ」を選択します。次に、既存グループのインポートリンクを選択します。
  2. GitLab 14.0以降が稼働しているGitLabインスタンスのURLを入力します。
  3. ソースGitLabインスタンスのパーソナルアクセストークンを入力します。
  4. Connect instanceを選択します。

インポートするグループとプロジェクトを選択します。

GitLab 15.8で導入された、プロジェクトあり/なしのグループをインポートするオプション。

ソースGitLabインスタンスへの作成者アクセスが許可されると、GitLabグループインポーターページにリダイレクトされます。ここでは、オーナーロールを持っている接続元インスタンスのトップレベルグループのリストを見ることができます。

  1. デフォルトでは、提案されたグループの名前空間はソースインスタンスに存在する名前と一致しますが、権限に基づいて、インポートを進める前にこれらの名前を編集することができます。
  2. インポートするグループの横で、いずれかを選択します:
    • プロジェクトと一緒にインポートします。
    • プロジェクトなしでインポート
  3. ステータス欄には、各グループのインポートステータスが表示されます。ページを開いたままにしておくと、リアルタイムで更新されます。
  4. グループがインポートされたら、GitLabパスを選択してGitLab URLを開いてください。
caution
プロジェクトとグループのインポートはベータ版です。この機能は本番環境では使用できません。

グループのインポート履歴

ダイレクトトランスファーでマイグレーションしたすべてのグループは、グループインポート履歴ページに一覧表示されます。このリストには以下が含まれます:

  • 移行元グループのパス。
  • デスティネーショングループのパス。
  • 各インポートの開始日。
  • 各インポートのステータス。
  • エラーが発生した場合は、エラーの詳細。

グループのインポート履歴を表示するには:

  1. GitLab にサインインします。
  2. 左サイドバーの上部にある「新規作成({プラス})」から新規グループ」を選択します。
  3. グループのインポートを選択します。
  4. 右上の「History」を選択します。
  5. 特定のインポートにエラーがある場合は、Detailsを選択するとエラーが表示されます。

マイグレーションされたグループアイテム

マイグレーションされるグループアイテムは、移行先で使用しているGitLabのバージョンによって異なります。特定のグループアイテムがマイグレーションされるかどうかを確認するには:

  1. すべてのエディションの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の場合:
  2. 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
  1. GitLab 15.4で導入されたエピックリソースの状態イベント、GitLab 13.12で導入されたラベルの関連付け、GitLab 13.7で導入された状態と状態ID、GitLab 14.0で導入されたシステムノートメタデータ。
  2. グループラベルは、インポート中に関連するラベルの優先順位を保持することはできません。これらのラベルは、関連するプロジェクトがインポート先のインスタンスにマイグレーションされた後、手動で優先順位を付け直す必要があります。
  3. グループメンバーは、ユーザーがインポートしたグループに関連付けられます:
    • 既にインポート先のGitLabインスタンスに存在している場合。
    • 送信元のGitLabインスタンスに、送信先のGitLabインスタンスで確認されたEメールと一致する公開Eメールがあること。

除外項目

マイグレーションから除外されるグループ項目があります:

  • 機密情報が含まれている可能性があります:CI/CD変数、Webhook、デプロイトークン。
  • サポートされていないもの: プッシュルール。

マイグレーションされたプロジェクトアイテム

  • GitLab 14.4 でbulk_import_projectsというフラグで導入されました。デフォルトでは無効になっています。
  • GitLab15.6でGitLab.comで有効に
  • bulk_import_projects GitLab 15.10で機能フラグを削除
  • GitLab 15.11でAPIを使ったプロジェクトのみのマイグレーションが追加されました。

マイグレーションするグループを選択する際にプロジェクトをマイグレーションすることを選択した場合、プロジェクトアイテムはプロジェクトと一緒にマイグレーションされます。

マイグレーションされるプロジェクトアイテムは、移行先で使用している GitLab のバージョンによって異なります。特定のプロジェクトアイテムがマイグレーションされるかどうかを確認するには:

  1. すべてのエディションの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 の場合:
  2. 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を使用してプロジェクトのみのマイグレーションを開始できます。

caution
直接転送によるグループのマイグレーション時にプロジェクトをマイグレーションすることは、ベータ版であり、本番環境での使用には適していません。

移行先のGitLabインスタンスにマイグレーションされるプロジェクト項目は以下の通りです:

プロジェクトアイテム次で導入されました
プロジェクトGitLab 14.4
Auto DevOpsGitLab 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
WikiGitLab 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::Entitystatus3 (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:

    1. 左のサイドバーで、Search(検索)を選択するか、Go to(移動)を選択してグループを探します。
    2. 設定] > [全般]を選択します。
    3. 詳細設定] を展開します。
    4. グループURLの変更]で、グループURLに数字以外の文字を含めるように変更します。
  • グループAPI.

その他の404 エラー

グループをインポートする際、例えば他の404 エラーが発生することがあります:

"exception_message": "Unsuccessful response 404 from [FILTERED] Bo...",
"exception_class": "BulkImports::NetworkError",

このエラーは、_ソース・_インスタンスからの転送に問題があることを示しています。このエラーを解決するには、ソース・インスタンスで前提条件を満たしていることを確認します。

マイグレーション期間の短縮

1回の直接転送マイグレーションでは、移行先インスタンスで利用可能なワーカーの数に関係なく、1回のインポートにつき5つのエンティティ(グループまたはプロジェクト)が実行されます。とはいえ、移行先インスタンスのワーカー数を増やすと、各エンティティのインポートにかかる時間が短縮され、マイグレーションが高速化されます。

デスティネーションインスタンスのワーカー数を増やすと、ソースインスタンスのハードウェアリソースが飽和するまでのマイグレーション期間を短縮できます。バッチでのリレーションのエクスポートとインポート(エピック9036で提案)は、デスティネーションインスタンスに十分な利用可能なワーカーを持つことをさらに有用にします。

ソースインスタンス上のワーカーの数は、(実行中のインポートごとに)5つの同時実行エンティティを並行してエクスポートするのに十分でなければなりません。そうでないと、デスティネーションがエクスポートされたデータが利用可能になるのを待っている間に、遅延やタイムアウトが発生する可能性があります。

プロジェクトを異なるグループにディストリビューションすると、タイムアウトを回避できます。複数の大規模プロジェクトが同じグループにある場合は、次のことができます:

  1. 大規模プロジェクトを別のグループまたはサブグループに移動します。
  2. グループやサブグループごとにマイグレーションを開始します。

GitLab UIではトップレベルのグループしかマイグレーションできません。APIを使って、サブグループをマイグレーションすることもできます。

エクスポートファイルをアップロードしてグループをマイグレーション(非推奨)

  • GitLab 13.0で実験的な機能として導入されました。今後のリリースで変更される可能性があります。
  • GitLab 14.6で非推奨
caution
この機能はGitLab 14.6では非推奨となり、直接転送によるグループのマイグレーションに置き換えられました。しかし、この機能はオフラインシステム間でのグループのマイグレーションにはまだ推奨されています。オフライン環境用の代替ソリューションの進捗を追うには、関連するエピックを参照してください。

前提条件:

  • マイグレーションするグループのオーナーロール。

ファイルエクスポートを使用すると、次のことができます:

  • 任意のグループをファイルにエクスポートし、そのファイルを別の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.013.0, 12.10, 12.9
13.113.1, 13.0, 12.10

エクスポート内容

グループ用のimport_export.yml ファイルは、ファイルエクスポートを使用してグループをマイグレーションする際にエクスポートおよびインポートされるアイテムの一覧です。移行先のGitLabインスタンスにインポートできるアイテムを確認するには、GitLabのバージョンのブランチでこのファイルを表示します。例えば、14-10-stable-ee ブランチのimport_export.yml

エクスポートされるグループアイテムは以下の通りです:

  • マイルストーン
  • グループラベル_(ラベルの優先順位_なし)
  • ボードとボードリスト
  • バッジ
  • サブグループ(前述のすべてのデータを含む)
  • エピック
    • エピックリソースの状態イベント(GitLab 15.4 で導入)
  • イベント
  • Wiki(GitLab 13.9 で導入)
  • イテレーションケイデンス(15.4 で導入)

エクスポートされない項目は以下の通りです:

  • プロジェクト
  • ランナートークン
  • SAML ディスカバリートークン

準備

  • インポートしたグループのメンバー リストとそれぞれの権限を保持するには、これらのグループのユーザーをレビューします。必要なグループをインポートする前に、これらのユーザーが存在することを確認してください。
  • ユーザーはインポート元のGitLabインスタンスで、インポート先のGitLabインスタンスで確認したプライマリEメールと一致する公開Eメールを設定する必要があります。ほとんどのユーザーは、Eメールアドレスの確認を求めるEメールを受け取ります。

グループのエクスポートを有効にします。

前提条件

  • グループのオーナーロールを持っている必要があります。

グループのインポートとエクスポートを有効にするには、以下の手順に従います:

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーで、設定 > 一般を選択します。
  4. 表示とアクセス制御] を展開します。
  5. ソースのインポート] セクションで、必要なソースのチェックボックスを選択します。

グループのエクスポート

前提条件:

  • グループのオーナーロールを持っている必要があります。

グループの内容をエクスポートするには:

  1. 左のサイドバーで、Search(検索)を選択するか、Go to(移動)を選択してグループを探します。
  2. 設定] > [全般]を選択します。
  3. 詳細設定]セクションで、[エクスポートグループ]を選択します。
  4. エクスポートが生成されると、圧縮されたtarアーカイブにエクスポートされたコンテンツへのリンクが記載されたメールが届きます。
  5. あるいは、UIからエクスポートをダウンロードすることもできます:

    1. グループの設定 > 一般ページに戻ります。
    2. 詳細」セクションで、「エクスポートをダウンロード」を選択します。また、Regenerate export(エクスポートの再生成)を選択して、新しいファイルを生成することもできます。

APIを使用してグループをエクスポートすることもできます。

グループのインポート

  1. 左サイドバーの上部にある「新規作成({プラス})」と新規サブグループ」を選択します。
  2. 既存のグループのインポートリンクを選択します。
  3. グループ名を入力します。
  4. 関連するグループ URL を承認または変更します。
  5. ファイルを選択…を選択します。
  6. グループのエクスポートセクションでエクスポートしたファイルを選択します。
  7. インポートを開始するには、インポートを選択します。

オペレーションが完了すると、新しくインポートされたグループページが表示されます。

note
インポートファイルの最大サイズは管理者が設定できます。デフォルトは0 (無制限)です。管理者として、最大インポートファイルサイズを変更することができます。これを行うには、アプリケーション設定APIまたは管理エリアのmax_import_size オプションを使用します。GitLab 13.8でデフォルトが50MBから0に変更されました。

レート制限

不正使用を避けるため、デフォルトではユーザーのレートが制限されています:

リクエストタイプリミット
エクスポート毎分6グループ
エクスポートのダウンロード1グループにつき1ダウンロード/分
インポート毎分6グループ

グループとプロジェクトのインポートを自動化

ユーザー、グループ、プロジェクトのインポートAPIコールの自動化については、グループとプロジェクトのインポートの自動化を参照してください。