Сведения о миграции репозитория с помощью GitHub Enterprise Importer
Необходимые компоненты
- Настоятельно рекомендуется выполнить пробную версию миграции и завершить рабочую миграцию в ближайшее время. Дополнительные сведения о пробных запусках см. в разделе "Обзор миграции из Azure DevOps в GitHub Enterprise Cloud".
- Убедитесь, что вы понимаете данные, которые будут перенесены, и известные ограничения поддержки импорта. Дополнительные сведения см. в разделе "Сведения о миграции из Azure DevOps в GitHub Enterprise Cloud".
- Хотя и не требуется, рекомендуется остановить работу во время рабочей миграции. Importer не поддерживает разностную миграцию, поэтому любые изменения, которые происходят во время миграции, не будут переноситься. Если вы решили не останавливать работу во время рабочей миграции, необходимо вручную перенести эти изменения.
- Для целевой организации на GitHub.comнеобходимо быть владелец организации или иметь роль миграции. Дополнительные сведения о роли миграции см. в разделе "Управление доступом к миграции из Azure DevOps".
Шаг 0. Подготовка к использованию API GraphQL GitHub
Чтобы сделать запросы GraphQL, вам потребуется написать собственные скрипты или использовать HTTP-клиент, такой как бессонница.
Дополнительные сведения о начале работы с API GraphQL GitHub GraphQL, включая аутентификацию, см. в разделе "Формирование вызовов с помощью GraphQL".
Шаг 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
}
}
}
Примечание. Обязательно используйте AZURE_DEVOPS для 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}/_git/{repository}. |
Требования к personal access token см. в разделе "Управление доступом к миграции из Azure DevOps".
Шаг 4. Проверка состояния миграции
Шаг 5. Проверка миграции и проверка журнала ошибок
Чтобы завершить миграцию, рекомендуется проверка проблему журнала миграции. Эта проблема создается на GitHub в целевом репозитории.
Наконец, мы рекомендуем просмотреть перенесенные репозитории для проверка звуки.
Шаг 1. Установка ADO2GH extension of the GitHub CLI
Если это первая миграция, необходимо установить ADO2GH extension of the GitHub CLI. Дополнительные сведения о GitHub CLIсм. в разделе "Сведения о GitHub CLI".
Кроме того, можно скачать автономный двоичный файл на странице выпусков для github/gh-ado2gh репозитория. Этот двоичный gh файл можно запускать напрямую без префикса.
-
Установите GitHub CLI. Инструкции по установке для GitHub CLI см. в репозитории GitHub CLI.
Примечание. Вам нужна версия 2.4.0 или более позднюю версию GitHub CLI. Вы можете проверка версию, установленную
gh --versionс помощью команды. -
Установите ADO2GH extension.
Shell gh extension install github/gh-ado2gh
gh extension install github/gh-ado2gh
В любой момент, когда вам нужна помощь с данными ADO2GH extension, можно использовать --help флаг с помощью команды. Например, gh ado2gh --help перечислит все доступные команды и gh ado2gh migrate-repo --help отобразит список всех параметров, доступных для migrate-repo команды.
Шаг 2. Обновление ADO2GH extension of the GitHub CLI
Данные ADO2GH extension of the GitHub CLI обновляются еженедельно. Чтобы убедиться, что вы используете последнюю версию, обновите расширение.
gh extension upgrade github/gh-ado2gh
gh extension upgrade github/gh-ado2gh
Шаг 3. Задание переменных среды
Прежде чем использовать ADO2GH extension для миграции на GitHub Enterprise Cloud, необходимо создать personal access tokens, которые могут получить доступ к исходным и целевым организациям, а затем задать personal access tokens в качестве переменных среды.
-
Создайте и запишите personal access token (classic), которая будет проходить проверку подлинности для целевой организации на GitHub Enterprise Cloud, убедившись, что маркер соответствует всем требованиям. Дополнительные сведения см. в разделе Управление доступом к миграции из Azure DevOps.
-
Создайте и запишите personal access token, которые будут проходить проверку подлинности для исходной организации в Azure DevOps, убедившись, что этот маркер соответствует всем требованиям. Дополнительные сведения см. в разделе Управление доступом к миграции из Azure DevOps.
-
Задайте переменные среды для personal access tokens, заменив TOKEN в командах ниже personal access token, записанных выше. Используется
GH_PATдля целевой организации иADO_PATдля исходной организации.-
Если вы используете терминал, используйте
exportкоманду.Shell export GH_PAT="TOKEN" export ADO_PAT="TOKEN"
export GH_PAT="TOKEN" export ADO_PAT="TOKEN" -
Если вы используете PowerShell, используйте
$envкоманду.Shell $env:GH_PAT="TOKEN" $env:ADO_PAT="TOKEN"
$env:GH_PAT="TOKEN" $env:ADO_PAT="TOKEN"
-
Шаг 4. Создание скрипта миграции
Если вы хотите перенести несколько репозиториев в GitHub Enterprise Cloud одновременно, используйте GitHub CLI для создания скрипта миграции. Результирующий скрипт будет содержать список команд миграции, по одному на репозиторий.
Примечание. Создание скрипта выводит скрипт PowerShell. Если вы используете терминал, вам потребуется вывести сценарий с .ps1 расширением файла и установить PowerShell для Mac[ или Linux, ](https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-macos?view=powershell-7.2)чтобы запустить его.
Если вы хотите перенести один репозиторий, перейдите к следующему шагу.
Создание скрипта миграции
Чтобы создать скрипт миграции, выполните gh ado2gh generate-script команду.
gh ado2gh generate-script --ado-org SOURCE --github-org DESTINATION --output FILENAME
gh ado2gh generate-script --ado-org SOURCE --github-org DESTINATION --output FILENAME
Чтобы добавить в скрипт дополнительные функциональные возможности, такие как перевораживание конвейеров, создание команд и настройку интеграции с Azure Boards, можно добавить --all флаг.
Если вы хотите, чтобы скрипт скачал журнал миграции для каждого перенесенного репозитория, добавьте --download-migration-logs флаг. Дополнительные сведения о журналах миграции см. в разделе "Доступ к журналам миграции для GitHub Enterprise Importer".
Замените заполнители в приведенной выше команде следующими значениями.
| Заполнитель | Значение |
|---|---|
| ИСТОЧНИК | Имя исходной организации |
| НАЗНАЧЕНИЕ | Имя целевой организации |
| FILENAME | Имя файла для результирующего скрипта миграции Если вы используете терминал, используйте .ps1 расширение файла в качестве созданного скрипта, чтобы запустить PowerShell. Вы можете установить PowerShell для Mac или Linux. |
Просмотр скрипта миграции
После создания скрипта просмотрите файл и, при необходимости, измените скрипт.
- Если есть какие-либо репозитории, которые вы не хотите перенести, удалить или закомментировать соответствующие строки.
- Если в целевой организации есть другое имя репозиториев, обновите значение соответствующего
--target-repoфлага.
Если вы скачали ADO2GH как автономный двоичный файл, а не как расширение для GitHub CLI, вам потребуется обновить созданный скрипт для запуска двоичного файла вместо gh ado2ghнего.
Шаг 5. Миграция репозиториев
Можно перенести несколько репозиториев с помощью скрипта миграции или одного репозитория с gh ado2gh migrate-repo помощью команды.
Перенос нескольких репозиториев
Перенос одного репозитория
Чтобы перенести один репозиторий, используйте gh ado2gh migrate-repo команду.
gh ado2gh migrate-repo --ado-org SOURCE --ado-team-project TEAM-PROJECT --ado-repo CURRENT-NAME --github-org DESTINATION --github-repo NEW-NAME
gh ado2gh migrate-repo --ado-org SOURCE --ado-team-project TEAM-PROJECT --ado-repo CURRENT-NAME --github-org DESTINATION --github-repo NEW-NAME
TEAM-PROJECT | Имя командного проекта репозитория, который требуется перенести
Если вы хотите отменить миграцию, используйте abort-migration команду, заменив идентификатор MIGRATION-ID возвращенным идентификатором migrate-repo.
gh ado2gh abort-migration --migration-id MIGRATION-ID
gh ado2gh abort-migration --migration-id MIGRATION-ID
Шаг 6. Проверка миграции и проверка журнала ошибок
По завершении миграции рекомендуется просмотреть журнал миграции. Дополнительные сведения см. в разделе Доступ к журналам миграции для GitHub Enterprise Importer.
Рекомендуется просмотреть перенесенные репозитории для проверка звуки.