Skip to main content

使用 GraphQL 将存储库从 Azure DevOps 迁移到 GitHub Enterprise Cloud

可以构建自己的工具,使用 GraphQL API 将存储库从 Azure DevOps 迁移到 GitHub Enterprise Cloud。

注意

还可以用 ADO2GH extension of the GitHub CLI 来执行迁移。 请参阅“阶段 1。 了解从 Azure DevOps 迁移到 GitHub”。

步骤 0:准备好使用 GitHub GraphQL API

要进行 GraphQL 查询,需要编写自己的脚本或使用 HTTP 客户端(如 Insomnia)。

若要详细了解 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:确定要从何处迁移

迁移源是 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 上组织的组织 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
    }
  }
}
查询变量说明
sourceIdcreateMigrationSource 突变返回的迁移源 id
ownerId组织在 GitHub Enterprise Cloud 上的组织 ID。
repositoryName组织在 GitHub Enterprise Cloud 上拥有的任何存储库当前未使用的自定义唯一存储库名称。 迁移完成或停止时,将在此存储库中创建一个错误记录问题。
continueOnError迁移设置,允许在遇到不会导致迁移失败的错误时继续迁移。 必须为 truefalse。 强烈建议将 continueOnError 设置为 true,以便继续迁移,除非 Importer 无法移动 Git 源,或 Importer 已断开连接且无法重新连接以完成迁移。
githubPat目标组织在 GitHub Enterprise Cloud 上的 personal access token。
accessToken源的 personal access token。
targetRepoVisibility新存储库的可见性。 必须为 privatepublicinternal。 如果未设置,则存储库将作为专用存储库迁移。
sourceRepositoryUrl源存储库的 URL,格式为 https://dev.azure.com/{organization}/{project}/_git/{repository}

有关 personal access token 要求的信息,请参阅 阶段 2。 管理访问权限

在下一步中,将使用从 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:验证迁移并检查错误日志

要完成迁移,建议检查“迁移日志”问题。 此问题在目标存储库中的 GitHub 上创建。

标题为“迁移日志”的问题的屏幕截图。 问题中的第二个注释包括迁移的日志。

最后,建议查看已迁移的存储库以进行完整性检查。

延伸阅读

  •         [AUTOTITLE](/migrations/ado/phase-6-follow-up-tasks)
    
  •         [AUTOTITLE](/migrations/ado/key-differences-between-azure-devops-and-github)