• 直接移行によるグループのマイグレーション（推奨）
  • 既知のイシュー
  • マイグレーション期間の見積もり
  • 限界
  • 可視性ルール
  • 前提条件
  • ユーザーアカウントの準備
  • 接続元の GitLab インスタンスに接続します。
  • インポートするグループとプロジェクトを選択します。
  • グループのインポート履歴
  • マイグレーションされたグループアイテム
    • 除外項目
  • マイグレーションされたプロジェクトアイテム
    • イシュー関連項目
    • マージリクエスト関連項目
    • 設定関連項目
    • 除外項目
  • トラブルシューティング
    • 古いインポート
    • エラー：404 Group Not Found
    • その他の404 エラー
    • マイグレーション期間の短縮
• エクスポートファイルをアップロードしてグループをマイグレーション（非推奨）
  • 互換性
  • エクスポート内容
  • 準備
  • グループのエクスポートを有効にします。
  • グループのエクスポート
  • グループのインポート
  • レート制限
• グループとプロジェクトのインポートを自動化

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_projects GitLab 15.10で機能フラグが削除されました。

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

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

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

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

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

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

グループをコピーする代わりにグループを移動したい場合、グループが同じGitLabインスタンスにあればグループを転送することができます。グループの転送はより速く、より完全なオプションです。

既知のイシュー

直接移籍によるマイグレーションに関する既知の問題については、エピック6629を参照してください。

マイグレーション期間の見積もり

直接移籍によるマイグレーション期間の見積もりは困難です。マイグレーション期間には以下の要因が影響します：

• 移行元と移行先の GitLab インスタンスで利用可能なハードウェアとデータベースのリソース。移行元と移行先のインスタンスのリソースが多いほど、マイグレーション期間が短くなります：
  • ソースインスタンスはAPIリクエストを受け取り、エクスポートするエンティティを抽出してシリアライズします。
  • デスティネーション・インスタンスはジョブを実行し、データベースにエンティティを作成します。
• エクスポートするデータの複雑さとサイズ。たとえば、それぞれ 1000 件のマージリクエストを持つ 2 つのプロジェクトをマイグレーションしたいとします。一方のプロジェクトのマージリクエストに添付ファイルやコメントなどの項目が多い場合、2つのプロジェクトの移行にかかる時間は大きく異なります。したがって、プロジェクトのマージリクエスト数は、プロジェクトのマイグレーションにかかる時間の予測にはなりません。

マイグレーションを確実に見積もる正確な公式はありません。しかし、プロジェクト関係をインポートする各パイプラインワーカーの平均所要時間は、プロジェクトのインポートにかかる時間の見当をつけるのに役立ちます：

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

限界

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

これらの API を使用して、リレーションシップの最大サイズ制限をテストできます：

• グループ関係エクスポート API。
• プロジェクト関係エクスポート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 がユーザーと貢献者を正しくマッピングするようにするため：

1. 移行先のGitLabインスタンスで必要なユーザーを作成します。API を使ってユーザーを作成できるのは、セルフマネージドインスタンスだけです。GitLab.comまたはセルフマネージドGitLabインスタンスにマイグレーションするときは、以下のことができます：
   • ユーザーを手動で作成します。
   • 既存のSAML SSOプロバイダを設定または使用し、SCIMを通じてサポートされるSAML SSOグループのユーザー同期を活用します。GitLabのユーザーアカウント認証を、認証済みのEメールドメインでバイパスすることができます。
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を開いてください。

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

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

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

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

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の場合：
   • https://gitlab.com/gitlab-org/gitlab/-/blob/15-9-stable-ee/lib/bulk_imports/groups/stage.rb(全エディション）。
   • https://gitlab.com/gitlab-org/gitlab/-/blob/15-9-stable-ee/ee/lib/ee/bulk_imports/groups/stage.rb(エンタープライズ版）。
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インスタンスにマイグレーションされるグループアイテムは以下の通りです：

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 の場合：
   • https://gitlab.com/gitlab-org/gitlab/-/blob/15-9-stable-ee/lib/bulk_imports/projects/stage.rb(全エディション）。
   • https://gitlab.com/gitlab-org/gitlab/-/blob/15-9-stable-ee/ee/lib/ee/bulk_imports/projects/stage.rb(エンタープライズ版）。
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を使用してプロジェクトのみのマイグレーションを開始できます。

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

イシュー関連項目

移行先のGitLabインスタンスにマイグレーションされるイシュー関連のプロジェクトアイテムには、以下のようなものがあります：

マージリクエスト関連項目

移行先の GitLab インスタンスにマイグレーションされるマージリクエスト関連のプロジェクトアイテムには、以下のようなものがあります：

設定関連項目

移行先のGitLabインスタンスにマイグレーションされる設定関連のプロジェクト項目には、以下のようなものがあります：

除外項目

いくつかのプロジェクトアイテムはマイグレーションから除外されます：

• 機密情報が含まれている可能性があります：
  • 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：

  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で非推奨。

前提条件：

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

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

• 任意のグループをファイルにエクスポートし、そのファイルを別の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つ前までのバージョンからエクスポートされたグループファイルをインポートすることができます。

使用例：

エクスポート内容

グループ用の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. インポートを開始するには、インポートを選択します。

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

レート制限

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

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

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