Skip to main content

GraphQL を使用して Azure DevOps から GitHub Enterprise Cloud にリポジトリを移行する

GraphQL API を使用して、リポジトリをAzure DevOpsからGitHub Enterprise Cloudに移行するための独自のツールを構築できます。

メモ

ADO2GH extension of the GitHub CLIを使用して移行を実行することもできます。 「Azure DevOpsからGitHubへの移行について理解する」を参照してください。

手順 0: GitHub GraphQL API を使用する準備をする

GraphQL クエリを作成するには、独自のスクリプトを記述するか、Insomnia などの HTTP クライアントを使う必要があります。

認証方法など、GitHub GraphQL API の概要については、「GraphQLでの呼び出しの作成」を参照してください。

すべての GraphQL クエリを、移行に送信します。 データ所在地付き GitHub Enterprise Cloud に移行する場合は、GHE.com のエンタープライズのサブドメインのエンドポイントにクエリを送信してください。

手順 1: 移行先のownerId を取得する

GitHub Enterprise Cloud の Organization 所有者として、GetOrgInfo クエリを使って、移行されたリポジトリを所有する Organization の ownerId (Organization ID とも呼ばれます) を取得します。 移行先を識別するには、ownerId が必要です。

GetOrgInfo クエリ

query(
  $login: String!
){
  organization (login: $login)
  {
    login
    id
    name
    databaseId
  }
}
クエリ変数説明
loginOrganization の名前。

GetOrgInfo の応答

{
  "data": {
    "organization": {
      "login": "Octo",
      "id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
      "name": "Octo-org",
      "databaseId": 5610
    }
  }
}

この例では、MDEyOk9yZ2FuaXphdGlvbjU2MTA= が Organization ID つまり ownerId であり、次のステップでそれを使います。

手順 2: 移行元の場所を特定する

createMigrationSource クエリを使って、移行元を設定できます。 GetOrgInfo クエリで収集した ownerId つまり Organization ID を指定する必要があります。

移行ソースは ADO 組織です。

createMigrationSource ミューテーション

mutation createMigrationSource($name: String!, $ownerId: ID!) {
  createMigrationSource(input: {name: $name, url: "https://dev.azure.com", ownerId: $ownerId, type: AZURE_DEVOPS}) {
    migrationSource {
      id
      name
      url
      type
    }
  }
}

メモ

type には AZURE_DEVOPS を使用するようにしてください。

クエリ変数説明
name移行元の名前。 この名前は自分の参照用であるため、任意の文字列を使用できます。
ownerIdGitHub Enterprise Cloud での Organization の Organization ID。

createMigrationSource 応答

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
        "name": "Azure DevOps Source",
        "url": "https://dev.azure.com",
        "type": "AZURE_DEVOPS"
      }
    }
  }
}

この例では、MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA が移行元 ID であり、次の手順で使います。

手順 3: リポジトリの移行を開始する

移行を始める、1 つのリポジトリとそれに付随するデータが、ユーザーが指定した新しい GitHub リポジトリに移行されます。

同じ移行元 Organization から複数のリポジトリを一度に移動したい場合は、複数の移行をキューに登録できます。 同時に最大 5 つのリポジトリの移行を実行できます。

startRepositoryMigration ミューテーション

mutation startRepositoryMigration (
  $sourceId: ID!,
  $ownerId: ID!,
  $sourceRepositoryUrl: URI!,
  $repositoryName: String!,
  $continueOnError: Boolean!,
  $accessToken: String!,
  $githubPat: String!,
  $targetRepoVisibility: String!
){
  startRepositoryMigration( input: {
    sourceId: $sourceId,
    ownerId: $ownerId,
    repositoryName: $repositoryName,
    continueOnError: $continueOnError,
    accessToken: $accessToken,
    githubPat: $githubPat,
    targetRepoVisibility: $targetRepoVisibility,
    sourceRepositoryUrl: $sourceRepositoryUrl,
  }) {
    repositoryMigration {
      id
      migrationSource {
        id
        name
        type
      }
      sourceUrl
    }
  }
}
クエリ変数説明
sourceIdcreateMigrationSource ミューテーションから返された移行元の id
ownerIdGitHub Enterprise Cloud での Organization の Organization ID。
repositoryNameGitHub Enterprise Cloud 上で Organization が所有するどのリポジトリでも現在使われていない一意のカスタム リポジトリ名。 移行が完了または停止すると、このリポジトリにエラー ログ issue が作成されます。
continueOnError移行の失敗を引き起こさないエラーが発生したときに移行を続行できるようにする移行設定。 true または false である必要があります。 Importer が Git ソースを移動できない場合、または Importer が接続を失い、移行を完了するために再接続できない場合を除き、移行が続けられるように、continueOnErrortrue に設定することを強くお勧めします。
githubPatpersonal access token 上の移行先 Organization の GitHub Enterprise Cloud。
accessToken移行元の personal access token。
targetRepoVisibility新しいリポジトリの可視性。 privatepublic、または internal にする必要があります。 設定されていない場合、リポジトリはプライベートとして移行されます。

| sourceRepositoryUrl | https://dev.azure.com/{organization}/{project}/_git/{repository}形式を使用したソース リポジトリの URL。

personal access token要件については、アクセスの管理 を参照してください。

次のステップでは、startRepositoryMigration ミューテーションから返された移行 ID を使って、移行の状態を調べます。

手順 4: 移行の状態を確認する

移行エラーを検出し、移行が行われていることを確認するには、getMigration クエリを使って移行の状態を調査できます。 また、getMigrations を使うと、複数の移行の状態を調べることもできます。

getMigration クエリから返される状態を調べて、移行が queuedin progressfailed、または completed であるかどうかを確認できます。 移行が失敗した場合、Importer によってエラーの原因が示されます。

getMigration クエリ

query (
  $id: ID!
){
  node( id: $id ) {
    ... on Migration {
      id
      sourceUrl
      migrationSource {
        name
      }
      state
      failureReason
    }
  }
}
クエリ変数説明
idstartRepositoryMigration ミューテーションが返した移行の id

手順 5: 移行を検証し、エラー ログを確認する

移行を完了するには、"移行ログ" の issue を確認することをお勧めします。 この issue は、移行先リポジトリの GitHub に作成されます。

"移行ログ" というタイトルの issue のスクリーンショット。 issue の 2 番目のコメントに、移行に関するログが含まれます。

最後に、移行したリポジトリで健全性チェックを確認することをお勧めします。

詳細については、次を参照してください。