移行データの準備
-
scp
コマンドを使用して、ソース インスタンスまたは組織から生成された移行アーカイブを GitHub Enterprise Server ターゲットにコピーします。scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/
-
ターゲットの GitHub Enterprise Server インスタンスに SSH で接続します。 詳しくは、「管理シェル (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
- 競合が報告されない場合、データを安全にインポートできます。
-
競合がある場合は、
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 |
project | https://example-gh.source/octo-org/widgets/projects/1 | https://example-gh.target/octo-org/projects/1 | merge |
conflicts.csv の各行には次の情報が示されます。
名前 | 説明 |
---|---|
model_name | 変更されるデータの種類。 |
source_url | データのソースURL。 |
target_url | 期待されるデータのターゲットURL。 |
recommended_action | データのインポート時に推奨されるアクション ghe-migrator が実行されます。 |
各レコードタイプで可能なマッピング
データの転送時に ghe-migrator
で実行できるいくつかの異なるマッピング アクションがあります。
action | 説明 | 適用可能なモデル |
---|---|---|
import | (デフォルト)ソースからのデータがターゲットにインポートされます。 | すべてのレコードタイプ |
map | ソース データに基づいて新しいモデルを作成する代わりに、ターゲット内の既存のレコードが使用されます。 リポジトリを既存の組織にインポートしたり、ターゲットのユーザー ID をソースのユーザー ID にマッピングしたりする場合に便利です。 | ユーザー、組織、プロジェクト |
rename | ソースからのデータは名前が変更されてターゲットにコピーされます。 | ユーザー、組織、リポジトリ、プロジェクト |
map_or_rename | ターゲットが存在する場合、そのターゲットにマップします。 そうでない場合はインポートされたモデルの名前を変更します。 | ユーザー |
merge | ソースからのデータはターゲット上の既存のデータと組み合わされます。 | Teams、プロジェクト |
conflicts.csv ファイルを確認し、ghe-migrator audit
を使用して、確実に適切なアクションが実行されるようにすることを強くお勧めします。 すべてが良好な場合、続行できます。
移行コンフリクトの解決もしくはカスタムマッピングのセットアップ
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
コマンドで競合がまだ存在することが報告された場合は、移行の競合解決プロセスをもう一度実行します。
インポートしたデータを GitHub Enterprise Server に適用する
-
ターゲットの GitHub Enterprise Server インスタンスに SSH で接続します。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。
ssh -p 122 admin@HOSTNAME
-
ghe-migrator import
コマンドを使用して、インポート プロセスを開始します。 必要なものは次のとおりです。- 移行 GUID。 詳細については、「G GitHub Enterprise Server にインポートするための移行データの準備」を参照してください。
- 認証のための personal access token。 私用する personal access token はサイト管理者としての認証専用です。特定のスコープまたはアクセス許可は必要ありません。 詳しくは、「個人用アクセス トークンを管理する」を参照してください。
$ ghe-migrator import /home/admin/MIGRATION-GUID.tar.gz -g MIGRATION-GUID -u USERNAME -p TOKEN > Starting GitHub::Migrator > Import 100% complete /
- 移行ファイルをステージングする場所を指定するには、
--staging-path=/full/staging/path
を使用してコマンドを追加します。 既定値は/data/user/tmp
です。
移行データのレビュー
既定では、ghe-migrator audit
はすべてのレコードを返します。 また、以下の条件でレコードをフィルタリングすることもできます。
- レコードのタイプ。
- レコードの状態。
レコードの種類は、移行されたデータで見つかったものと一致します。
レコードタイプのフィルタ
レコード タイプ | フィルター名 |
---|---|
ユーザー | user |
組織 | organization |
リポジトリ | repository |
Teams | team |
マイルストーン | milestone |
Projects (Classic) | project |
発行 | issue |
Issueのコメント | issue_comment |
Pull Request | pull_request |
プルリクエストのレビュー | pull_request_review |
コミットのコメント | commit_comment |
プルリクエストのレビューのコメント | pull_request_review_comment |
リリース | release |
プルリクエストあるいはIssueに対して行われたアクション | issue_event |
保護されたブランチ | protected_branch |
レコードの状態フィルタ
レコードの状態 | 説明 |
---|---|
export | レコードはエクスポートされます。 |
import | レコードはインポートされます。 |
map | レコードはマップされます。 |
rename | レコードの名前が変更されます。 |
merge | レコードはマージされます。 |
exported | レコードはエクスポートに成功しました。 |
imported | レコードはインポートに成功しました。 |
mapped | レコードはマップに成功しました。 |
renamed | レコードの名前の変更に成功しました。 |
merged | レコードはマージに成功しました。 |
failed_export | レコードはエクスポートに失敗しました。 |
failed_import | レコードはインポートに失敗しました。 |
failed_map | レコードはマップに失敗しました。 |
failed_rename | レコードの名前の変更に失敗しました。 |
failed_merge | レコードはマージに失敗しました。 |
監査されたレコードのフィルタリング
ghe-migrator audit
コマンドを使用すると、-m
フラグを使用してレコードの種類に基づいてフィルター処理できます。 同様に、-s
フラグを使用してインポート状態をフィルター処理できます。 次のようなコマンドです。
ghe-migrator audit -m RECORD_TYPE -s STATE -g MIGRATION-GUID
たとえば、インポートに成功したすべての組織とチームを見るには以下のようにします。
$ ghe-migrator audit -m organization,team -s mapped,renamed -g MIGRATION-GUID
> model_name,source_url,target_url,state
> organization,https://gh.source/octo-org/,https://ghe.target/octo-org/,renamed
失敗したすべてのインポートを監査することを強くお勧めします。 これを行うには、次のように入力します。
$ ghe-migrator audit -s failed_import,failed_map,failed_rename,failed_merge -g MIGRATION-GUID
> model_name,source_url,target_url,state
> user,https://gh.source/octocat,https://gh.target/octocat,failed
> repository,https://gh.source/octo-org/octo-project,https://ghe.target/octo-org/octo-project,failed
失敗したインポートに関する懸念がある場合は、GitHub Enterprise サポートにアクセスしてお問い合わせください。
GitHub Enterprise Server でインポートを完了する
ターゲットインスタンスへの移行が適用され、その内容を確認したら、リポジトリのロックを解除して、ソースから削除します。 ソースデータを削除する前に、すべてが期待どおりに機能していることを確認するため2週間ほど待つことをおすすめします。
ターゲットインスタンス上でのリポジトリのアンロック
-
お使いの GitHub Enterprise Server インスタンス に SSH で接続します。 インスタンスが複数のノードで構成されている場合は (高可用性や geo レプリケーションが構成されている場合など)、プライマリ ノードに SSH 接続します。 クラスターを使用する場合は、任意のノードに SSH 接続できます。 HOSTNAME をインスタンスのホスト名、またはノードのホスト名または IP アドレスに置き換えます。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。
Shell ssh -p 122 admin@HOSTNAME
ssh -p 122 admin@HOSTNAME
-
ghe-migrator unlock
コマンドを使用して、インポートされたすべてのリポジトリのロックを解除します。 移行GUIDが必要になります。
$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project
警告: schedule
トリガーを使用してリポジトリに GitHub Actions ワークフローが含まれている場合、ワークフローはインポート後に自動的に実行されません。 スケジュールされたワークフローをもう一度開始するには、リポジトリにコミットをプッシュします。 詳しくは、「ワークフローをトリガーするイベント」を参照してください。
ソース上でのリポジトリのアンロック
移行が完了したら、ソースのリポジトリのロックを解除する必要があります。
GitHub.com で組織からリポジトリのロックを解除する
GitHub.com組織のリポジトリのロックを解除するには、DELETE
要求を移行ロック解除エンドポイントに送信します。 必要なものは次のとおりです。
- 認証のためのアクセストークン
- 移行の一意の
id
- アンロックするリポジトリの名前
curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
-H "Accept: application/vnd.github.wyandotte-preview+json" \
https://api.github.com/orgs/ORG-NAME/migrations/ID/repos/REPO_NAME/lock
GitHub.com で組織からリポジトリを削除する
GitHub.com組織のリポジトリのロックを解除した後、リポジトリ削除エンドポイントを使用して以前に移行したすべてのリポジトリを削除する必要があります。 認証のためのアクセストークンが必要になります。
curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
https://api.github.com/repos/ORG-NAME/REPO_NAME
GitHub Enterprise Server インスタンスからリポジトリをアンロックする
-
お使いの GitHub Enterprise Server インスタンス に SSH で接続します。 インスタンスが複数のノードで構成されている場合は (高可用性や geo レプリケーションが構成されている場合など)、プライマリ ノードに SSH 接続します。 クラスターを使用する場合は、任意のノードに SSH 接続できます。 HOSTNAME をインスタンスのホスト名、またはノードのホスト名または IP アドレスに置き換えます。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。
Shell ssh -p 122 admin@HOSTNAME
ssh -p 122 admin@HOSTNAME
-
ghe-migrator unlock
コマンドを使用して、インポートされたすべてのリポジトリのロックを解除します。 移行GUIDが必要になります。
$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project