使用 GraphQL 将代码仓库从 Azure DevOps 迁移到 GitHub Enterprise Cloud

步骤 0：准备使用 GitHub GraphQL API

要进行 GraphQL 查询，您需要编写自己的脚本或使用诸如 Insomnia 之类的 HTTP 客户端。

想了解更多关于开始使用 GitHub GraphQL API 的信息，包括如何进行身份验证，请参阅 使用 GraphQL 发起调用。

您需要将所有 GraphQL 查询发送到迁移的目标。如果您迁移到具有数据驻留要求的 GitHub Enterprise Cloud，请确保将查询发送到您企业 GHE.com 子域的端点。

步骤 1：获取迁移目标的 ownerId

作为 GitHub Enterprise Cloud 中的组织所有者，请使用 GetOrgInfo 查询返回 ownerId（也称为组织 ID），即您希望拥有迁移后仓库的组织。您需要使用 ownerId 来确定迁移目标。

GetOrgInfo 查询

query(
  $login: String!
){
  organization (login: $login)
  {
    login
    id
    name
    databaseId
  }
}

查询变量	描述
login	您的组织名称。

GetOrgInfo 响应

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

在本例中，MDEyOk9yZ2FuaXphdGlvbjU2MTA= 是组织 ID 或 ownerId，我们将在下一步中使用它。

步骤 2：确定迁移来源

您可以使用 createMigrationSource 查询设置迁移来源。您需要提供从 GetOrgInfo 查询获得的 ownerId（组织 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
    }
  }
}

查询变量	描述
name	迁移来源的名称。此名称仅供您参考，您可以使用任意字符串。
ownerId	您在 GitHub Enterprise Cloud 上的组织 ID。

createMigrationSource 响应

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

在本例中，MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA 是迁移来源 ID，我们将在下一步中使用它。

步骤 3：开始仓库迁移

当您启动迁移时，单个仓库及其相关数据将迁移到您指定的全新 GitHub 仓库中。

如果您想一次从同一来源组织迁移多个仓库，可以排队多个迁移。您最多可以同时运行 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
    }
  }
}

查询变量	描述
sourceId	您从 createMigrationSource 变更返回的迁移来源 id。
ownerId	您在 GitHub Enterprise Cloud 上的组织 ID。
repositoryName	一个自定义的唯一仓库名称，当前在 GitHub Enterprise Cloud 上的组织所拥有的仓库中未被使用。当迁移完成或停止时，将在此仓库中创建一个错误日志 issue。
continueOnError	迁移设置，允许在遇到不会导致迁移失败的错误时继续迁移。必须为 true 或 false。我们强烈建议将 continueOnError 设置为 true，这样除非 Importer 无法移动 Git 源或失去连接且无法重新连接完成迁移，否则迁移将继续进行。
githubPat	您在 GitHub Enterprise Cloud 上的目标组织的个人访问令牌。
accessToken	您来源的个人访问令牌。
targetRepoVisibility	新仓库的可见性。必须为 private、public 或 internal。如果未设置，仓库将以私有方式迁移。
sourceRepositoryUrl	来源仓库的 URL，格式为 https://dev.azure.com/{organization}/{project}/_git/{repository}。

有关个人访问令牌的要求，请参阅 管理访问。

在下一步中，您将使用 startRepositoryMigration 变更返回的迁移 ID 来检查迁移状态。

步骤 4：检查迁移状态

为了检测任何迁移失败并确保迁移正常工作，您可以使用 getMigration 查询检查迁移状态。您还可以使用 getMigrations 检查多个迁移的状态。

getMigration 查询将返回状态，告知迁移是 queued（已排队）、in progress（进行中）、failed（失败）还是 completed（已完成）。如果迁移失败，Importer 将提供失败原因。

getMigration 查询

query (
  $id: ID!
){
  node( id: $id ) {
    ... on Migration {
      id
      sourceUrl
      migrationSource {
        name
      }
      state
      failureReason
    }
  }
}

查询变量	描述
id	您迁移的 id，该 ID 由 startRepositoryMigration 变更返回。

步骤 5：验证迁移并检查错误日志

要完成迁移，我们建议您检查 “Migration Log” issue。该 issue 会在目标仓库的 GitHub 中创建。

最后，建议您检查已迁移的仓库，以确保其完整性。

延伸阅读

• 后续任务
• Azure DevOps 与 GitHub 的关键区别