Skip to main content

このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 2024-03-26. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

GitHub エンタープライズServer にデータを移行する

移行アーカイブを作成すると、ターゲットの GitHub Enterprise Server インスタンスにデータをインポートできます。 変更を恒久的にターゲットのインスタンスに適用する前に、潜在的なコンフリクトがないか変更をレビューできます。

移行データの準備

  1. scp コマンドを使用して、ソース インスタンスまたは組織から生成された移行アーカイブを GitHub Enterprise Server ターゲットにコピーします。

    scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/
    
  2. ターゲットの GitHub Enterprise Server インスタンスに SSH で接続します。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

    ssh -p 122 admin@HOSTNAME
    
  3. 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 です。

移行のコンフリクトのリストの生成

  1. 移行 GUID を指定した ghe-migrator conflicts コマンドを使用して、conflicts.csv ファイルを生成します。

    ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv
    
    • 競合が報告されない場合、データを安全にインポートできます。
  2. 競合がある場合は、scp コマンドを使用して、conflicts.csv をローカル コンピューターにコピーします。

    scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop
    
  3. 移行コンフリクトの解決もしくはカスタム マッピングのセットアップ」に進みます。

移行コンフリクトのレビュー

  1. テキスト エディターまたは CSV 互換のスプレッドシート ソフトウェアを使用して、conflicts.csv を開きます。
  2. 以下の例と参照表のガイダンスを使用して、conflicts.csv ファイルを確認し、確実にインポート時に適切なアクションが実行されるようにします。

conflicts.csv ファイルには、競合の ''移行マップ'' と推奨アクションが含まれています。 移行マップは、ソースから移行されるデータと、そのデータがどのようにターゲットに適用されるかのリストです。

model_namesource_urltarget_urlrecommended_action
userhttps://example-gh.source/octocathttps://example-gh.target/octocatmap
organizationhttps://example-gh.source/octo-orghttps://example-gh.target/octo-orgmap
repositoryhttps://example-gh.source/octo-org/widgetshttps://example-gh.target/octo-org/widgetsrename
teamhttps://example-gh.source/orgs/octo-org/teams/adminshttps://example-gh.target/orgs/octo-org/teams/adminsmerge
projecthttps://example-gh.source/octo-org/widgets/projects/1https://example-gh.target/octo-org/projects/1merge

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_namesource_urltarget_urlrecommended_action
userhttps://example-gh.source/octocathttps://example-gh.target/octocatmap

このユーザをターゲット上の他のユーザにマップさせることができます。 octocat が実際にはターゲットの monalisa であるべきだとわかっているとします。 monalisa を示すように、conflicts.csvtarget_url 列を変更することができます。

model_namesource_urltarget_urlrecommended_action
userhttps://example-gh.source/octocathttps://example-gh.target/monalisamap

別の例として、octo-org/widgets リポジトリの名前をターゲット インスタンスの octo-org/amazing-widgets に変更する場合は、target_urlocto-org/amazing-widgets、および recommend_actionrename に変更します。

model_namesource_urltarget_urlrecommended_action
repositoryhttps://example-gh.source/octo-org/widgetshttps://example-gh.target/octo-org/amazing-widgetsrename

カスタムマッピングの追加

移行における一般的なシナリオは、移行されたユーザがターゲット上ではソース上とは異なるユーザ名を持つことです。

ソースのユーザ名のリストとターゲットのユーザー名のリストがあれば、カスタムマッピングの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.targetmonalisa に変更するには、次の内容の行を作成します。

model_namesource_urltarget_urlstate
userhttps://example-gh.source/octocathttps://example-gh.target/monalisarename

同じプロセスは、カスタムマッピングをサポートする各レコードのマッピングを作成するために使うことができます。 詳細については、レコードで可能なマッピングに関する表を参照してください。

修正された移行データの適用

  1. 変更を行った後、scp コマンドを使用して、変更した conflicts.csv (または正しい形式の他のマッピング .csv ファイル) をターゲット インスタンスに適用します。

    scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/
    
  2. ghe-migrator map コマンドを使用して移行データを再マップし、変更した .csv ファイルと移行 GUID へのパスを渡します。

    ghe-migrator map -i conflicts.csv  -g MIGRATION-GUID
    
  3. ghe-migrator map -i conflicts.csv -g MIGRATION-GUID コマンドで競合がまだ存在することが報告された場合は、移行の競合解決プロセスをもう一度実行します。

インポートしたデータを GitHub Enterprise Server に適用する

  1. ターゲットの GitHub Enterprise Server インスタンスに SSH で接続します。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

    ssh -p 122 admin@HOSTNAME
    
  2. ghe-migrator import コマンドを使用して、インポート プロセスを開始します。 必要なものは次のとおりです。

    $ 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
Teamsteam
マイルストーンmilestone
プロジェクト (クラシック)project
発行issue
Issueのコメントissue_comment
Pull Requestpull_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週間ほど待つことをおすすめします。

ターゲットインスタンス上でのリポジトリのアンロック

  1. お使いの GitHub Enterprise Server インスタンス に SSH で接続します。 インスタンスが複数のノードで構成されている場合は (高可用性や geo レプリケーションが構成されている場合など)、プライマリ ノードに SSH 接続します。 クラスターを使用する場合は、任意のノードに SSH 接続できます。 HOSTNAME をインスタンスのホスト名、またはノードのホスト名または IP アドレスに置き換えます。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

    Shell
    ssh -p 122 admin@HOSTNAME
    
  2. 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 インスタンスからリポジトリをアンロックする

  1. お使いの GitHub Enterprise Server インスタンス に SSH で接続します。 インスタンスが複数のノードで構成されている場合は (高可用性や geo レプリケーションが構成されている場合など)、プライマリ ノードに SSH 接続します。 クラスターを使用する場合は、任意のノードに SSH 接続できます。 HOSTNAME をインスタンスのホスト名、またはノードのホスト名または IP アドレスに置き換えます。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

    Shell
    ssh -p 122 admin@HOSTNAME
    
  2. ghe-migrator unlock コマンドを使用して、インポートされたすべてのリポジトリのロックを解除します。 移行GUIDが必要になります。

$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project