移行したデータを GitHub Enterprise Server にインポートするための準備
-
scp
コマンドを使用して、ソース インスタンスまたは Organization から生成された移行アーカイブを GitHub Enterprise Server ターゲットにコピーします。$ scp -P 122 /path/to/archive/MIGRATION_GUID.tar.gz admin@hostname:/home/admin/
-
サイト管理者として、ターゲットの GitHub Enterprise Server インスタンスに SSH で接続します。
$ ssh -p 122 admin@HOSTNAME
-
ghe-migrator prepare
コマンドを使ってターゲット インスタンスにインポートするためのアーカイブを準備し、以降の手� �で使用する新しい移行 GUID を生成します。ghe-migrator prepare /home/admin/MIGRATION_GUID.tar.gz
- 新しいインポートの試行を開始するには、もう一度
ghe-migrator prepare
を実行し、新しい移行 GUID を取得します。 - 移行ファイルをステージングする� �所を指定するには、
--staging-path=/full/staging/path
を使用してコマンドを追� します。 既定値は/data/user/tmp
です。
- 新しいインポートの試行を開始するには、もう一度
移行のコンフリクトのリストの生成
- 移行 GUID を指定した
ghe-migrator conflicts
コマンドを使用して、conflicts.csv ファイルを生成します。$ ghe-migrator conflicts -g MIGRATION_GUID > conflicts.csv
- 競合が� �告されない� �合は、「Enterprise にデータを移行する」の手� �に従って、データを安全にインポートできます。
- 競合がある� �合は、
scp
コマンドを使用して、conflicts.csv をローカル コンピューターにコピーします。$ scp -P 122 admin@hostname:conflicts.csv ~/Desktop
- 「移行コンフリクトの解決もしくはカスタ� マッピングのセットアップ」に進みます。
移行コンフリクトのレビュー
- テキスト エディターまたは CSV 互換のスプレッドシート ソフトウェアを使用して、conflicts.csv を開きます。
- 以下の例と参照表のガイダンスを使用して、conflicts.csv ファイルを確認し、確実にインポート時に適切なアクションが実行されるようにします。
conflicts.csv ファイルには、競合の ''移行マップ'' と推奨アクションが含まれています。 移行マップは、ソースから移行されるデータと、そのデータがどのようにターゲットに適用されるかのリストです。
model_name | source_url | target_url | recommended_action |
---|---|---|---|
user | https://example-gh.source/octocat | https://example-gh.target/octocat | map |
organization | https://example-gh.source/octo-org | https://example-gh.target/octo-org | map |
repository | https://example-gh.source/octo-org/widgets | https://example-gh.target/octo-org/widgets | rename |
team | https://example-gh.source/orgs/octo-org/teams/admins | https://example-gh.target/orgs/octo-org/teams/admins | merge |
conflicts.csv の各行には次の情� �が示されます。
名前 | 説明 |
---|---|
model_name | 変更されるデータの種類。 |
source_url | データのソースURL。 |
target_url | 期待されるデータのターゲットURL。 |
recommended_action | データのインポート時に推奨されるアクション ghe-migrator が実行されます。 |
各レコードタイプで可能なマッピング
データの転送時に ghe-migrator
で実行できるいくつかの異なるマッピング アクションがあります。
action | 説明 | 適用可能なモデル |
---|---|---|
import | (デフォルト)ソースからのデータがターゲットにインポートされます。 | すべてのレコードタイプ |
map | ソースからのデータがターゲット上の既存のデータで置き換えられます。 | Users、organizations、repositories |
rename | ソースからのデータは名前が変更されてターゲットにコピーされます。 | Users、organizations、repositories |
map_or_rename | ターゲットが存在する� �合、そのターゲットにマップします。 そうでない� �合はインポートされたモデルの名前を変更します。 | ユーザー |
merge | ソースからのデータはターゲット上の既存のデータと組み合わされます。 | Teams |
conflicts.csv ファイルを確認し、ghe-migrator audit
を使用して、確実に適切なアクションが実行されるようにすることを強くお勧めします。 すべて問題ないようであれば、「Enterprise にデータを移行する」に進むことができます。
移行コンフリクトの解決もしくはカスタ� マッピングのセットアップ
ghe-migrator
で正しくない変更が行われると思われる� �合は、conflicts.csv 内でデータを変更することによって修正できます。 conflicts.csv 内の任意の行を変更できます。
たとえば、ソースの octocat
ユーザーがターゲットの octocat
にマップされていることに気付いたとしましょう。
model_name | source_url | target_url | recommended_action |
---|---|---|---|
user | https://example-gh.source/octocat | https://example-gh.target/octocat | map |
このユーザをターゲット上の他のユーザにマップさせることができます。 octocat
が実際にはターゲットの monalisa
であるべき� とわかっているとします。 monalisa
を示すように、conflicts.csv の target_url
列を変更することができます。
model_name | source_url | target_url | recommended_action |
---|---|---|---|
user | https://example-gh.source/octocat | https://example-gh.target/monalisa | map |
別の例として、octo-org/widgets
リポジトリの名前をターゲット インスタンスの octo-org/amazing-widgets
に変更する� �合は、target_url
を octo-org/amazing-widgets
、および recommend_action
を rename
に変更します。
model_name | source_url | target_url | recommended_action |
---|---|---|---|
repository | https://example-gh.source/octo-org/widgets | https://example-gh.target/octo-org/amazing-widgets | rename |
カスタ� マッピングの追�
移行における一般的なシナリオは、移行されたユーザがターゲット上ではソース上とは異なるユーザ名を持つことです。
ソースのユーザ名のリストとターゲットのユーザー名のリストがあれば、カスタ� マッピングのCSVファイルを構築し、各ユーザのユーザ名とコンテンツが移行の終了時点で正しく割り当てられているようにそのファイルを適用できます。
ghe-migrator audit
コマンドを使用して、カスタ� マッピングを適用するために必要な CSV 形式で、移行されるユーザーの CSV をすばやく生成できます。
$ ghe-migrator audit -m user -g MIGRATION_GUID > users.csv
これで、その CSV を編集し、マップまたは名前を変更する各ユーザーの新しい URL を入力してから、4 番目の列を更新し、適宜、map
または rename
が含まれるようにすることができます。
たとえば、ユーザー octocat
の名前をターゲット https://example-gh.target
の monalisa
に変更するには、次の内容の行を作成します。
model_name | source_url | target_url | state |
---|---|---|---|
user | https://example-gh.source/octocat | https://example-gh.target/monalisa | rename |
同じプロセスは、カスタ� マッピングをサポートする各レコードのマッピングを作成するために使うことができます。 詳細については、レコードで可能なマッピングに関する表を参照してく� さい。
修正された移行データの適用
-
変更を行った後、
scp
コマンドを使用して、変更した conflicts.csv (または正しい形式の他のマッピング .csv ファイル) をターゲット インスタンスに適用します。$ scp -P 122 ~/Desktop/conflicts.csv admin@hostname:/home/admin/
-
ghe-migrator map
コマンドを使用して移行データを再マップし、変更した .csv ファイルと移行 GUID へのパスを渡します。$ ghe-migrator map -i conflicts.csv -g MIGRATION_GUID
-
ghe-migrator map -i conflicts.csv -g MIGRATION_GUID
コマンドで競合がま� 存在することが� �告された� �合は、移行の競合解決プロセスをもう一度実行します。