Skip to main content

Перенос репозиториев из GitHub.com в GitHub Enterprise Cloud

Репозитории можно перенести с GitHub.com на GitHub Enterprise Cloud, используя GitHub CLI или API GraphQL.

Tool navigation

Сведения о миграции репозитория с помощью GitHub Enterprise Importer

Миграции на GitHub Enterprise Cloud включают миграцию между учетными записями на GitHub.com и, если вы принимаете Место расположения данных, миграция в поддомен вашего предприятия GHE.com.

Чтобы просмотреть инструкции по использованию GitHub CLI, используйте переключатель инструментов в верхней части страницы.

Необходимые компоненты

  • Настоятельно рекомендуется выполнить пробную версию миграции и завершить рабочую миграцию в ближайшее время. Дополнительные сведения о пробных запусках см. в разделе Обзор миграции между продуктами GitHub.
  • Убедитесь, что вы понимаете данные, которые будут перенесены, и известные ограничения поддержки импорта. Дополнительные сведения см. в разделе Сведения о миграции между продуктами GitHub.
  • Хотя и не требуется, рекомендуется остановить работу во время рабочей миграции. Importer не поддерживает разностную миграцию, поэтому любые изменения, которые происходят во время миграции, не будут переноситься. Если вы решили не останавливать работу во время рабочей миграции, необходимо вручную перенести эти изменения.
  • В исходной и целевой организации необходимо либо владелец организации, либо предоставить роль миграции. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.

Шаг 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 из запроса.

Источник миграции — это организация на GitHub.com.

createMigrationSource мутация

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

Note

Обязательно используйте GITHUB_ARCHIVE для type.

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

createMigrationSource ответ

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
        "name": "GitHub.com Source",
        "url": "https://github.com",
        "type": "GITHUB_SOURCE"
      }
    }
  }
}

В этом примере 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 потерял соединение и не сможет повторно подключиться к миграции.
githubPatpersonal access token для целевой организации на GitHub Enterprise Cloud.
accessTokenpersonal access token для источника.
targetRepoVisibilityВидимость нового репозитория. Должно быть private, public или internal. Если этот параметр не задан, репозиторий переносится как закрытый.
sourceRepositoryUrlURL-адрес исходного репозитория с использованием формата https://github.com/{organization}/{repository}.

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

На следующем шаге вы будете использовать идентификатор миграции, возвращенный из 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 в целевом репозитории.

Снимок экрана: проблема с заголовком "Журнал миграции". Второй комментарий в этой проблеме включает журналы для миграции.

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