Use GraphQL to migrate repositories from Azure DevOps to GitHub Enterprise Cloud

Шаг 0. Подготовка к использованию API GraphQL GitHub

Чтобы сделать запросы GraphQL, вам потребуется написать собственные скрипты или использовать HTTP-клиент, такой как бессонница.

Дополнительные сведения о начале работы с API GraphQL GitHub GraphQL, включая проверку подлинности, см. в статье Формирование вызовов с помощью GraphQL.

Все запросы GraphQL отправляются в место назначения миграции. Если вы переносите данные GitHub Enterprise Cloud с размещением данных, обязательно отправьте запросы в конечную точку поддомена вашего предприятия GHE.com.

Шаг 1. Получение ownerId назначения миграции

В качестве владелец организации в GitHub Enterprise Cloudиспользуйте GetOrgInfo запрос для возврата ownerIdидентификатора организации, которая также называется идентификатором организации, для которой требуется принадлежать перенесенные репозитории. Вам потребуется ownerId определить назначение миграции.

GetOrgInfo запрос

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

Переменная запроса	Description
login	Имя вашей организации.

GetOrgInfo ответ

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

В этом примере MDEyOk9yZ2FuaXphdGlvbjU2MTA= — это идентификатор организации или ownerIdидентификатор организации, который мы будем использовать на следующем шаге.

Шаг 2. Определение места миграции из

Вы можете настроить источник миграции с помощью createMigrationSource запроса. Вам потребуется указать ownerIdидентификатор организации, собранный GetOrgInfo из запроса.

Источник миграции — это ваша организация 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
    }
  }
}

Переменная запроса	Description
name	Имя источника миграции. Это имя для собственной ссылки, поэтому можно использовать любую строку.
ownerId	Идентификатор организации в GitHub Enterprise Cloud.

          `createMigrationSource` ответ

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

В этом примере MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA — это идентификатор источника миграции, который мы будем использовать на следующем шаге.

Шаг 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
    }
  }
}

Переменная запроса	Description
sourceId	Источник миграции id вернулся из мутации createMigrationSource .
ownerId	Идентификатор организации в GitHub Enterprise Cloud.
repositoryName	Пользовательское уникальное имя репозитория, которое в настоящее время не используется ни одной из репозиториев, принадлежащих организации, на GitHub Enterprise Cloud. Проблема с ведением журнала ошибок будет создана в этом репозитории при завершении или остановке миграции.
continueOnError	Параметр миграции, позволяющий продолжить миграцию при возникновении ошибок, которые не вызывают сбой миграции. Должно быть true или false. Настоятельно рекомендуется задать значение continueOnError true , чтобы миграция продолжалась, если только Importer не может переместить источник Git или Importer потерял соединение и не сможет повторно подключиться к миграции.
githubPat	personal access token для целевой организации на GitHub Enterprise Cloud.
accessToken	personal access token для источника.
targetRepoVisibility	Видимость нового репозитория. Должно быть private, public или internal. Если этот параметр не задан, репозиторий переносится как закрытый.
sourceRepositoryUrl	URL-адрес исходного репозитория с использованием формата https://dev.azure.com/{organization}/{project}/_git/{repository}.

Требования к personal access token см. в разделе Управление доступом.

На следующем шаге вы будете использовать идентификатор миграции, возвращенный из startRepositoryMigration изменения, чтобы проверить состояние миграции.

Шаг 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
    }
  }
}

Переменная запроса	Description
id	Миграцияid, возвращаемая мутациейstartRepositoryMigration.

Шаг 5. Проверка миграции и проверка журнала ошибок

Чтобы завершить миграцию, рекомендуется проверить проблему журнала миграции. Эта проблема создается на GitHub в целевом репозитории.

Наконец, рекомендуется просмотреть перенесенные репозитории для проверки звука.

Дополнительные материалы

• Дальнейшие задачи
• Ключевые отличия между Azure DevOps и GitHub