Сведения о миграции репозитория с помощью GitHub Enterprise Importer
Если вы решили использовать API, вам потребуется написать собственные скрипты или использовать HTTP-клиент, такой как бессонница. Дополнительные сведения о начале работы с api GitHubв [AUTOTITLE и Начало работы с REST API](/graphql/guides/forming-calls-with-graphql).
Чтобы перенести репозитории из GitHub Enterprise Server на GitHub Enterprise Cloud с помощью API, выполните следующие действия:
- Создание personal access token для исходной и целевой организации
ownerId
Получение целевой организации на GitHub Enterprise Cloud- Настройка источника миграции с помощью API GraphQL GitHub, чтобы определить, откуда выполняется миграция
- Для каждого репозитория, который требуется перенести, повторите эти действия.
- Использование REST API в экземпляр GitHub Enterprise Server для создания архивов миграции для репозитория
- Отправка архивов миграции в расположение, к которым можно получить доступ с помощью GitHub
- Запустите миграцию с помощью API GraphQL для назначения миграции, передавая URL-адреса архива
- Проверьте состояние миграции с помощью API GraphQL
- Проверка миграции и проверка журнала ошибок
Чтобы просмотреть инструкции по использованию GitHub CLI, используйте переключатель инструментов в верхней части страницы.
Необходимые компоненты
- Настоятельно рекомендуется выполнить пробную версию миграции и завершить рабочую миграцию в ближайшее время. Дополнительные сведения о пробных запусках см. в разделе Обзор миграции между продуктами GitHub.
- Убедитесь, что вы понимаете данные, которые будут перенесены, и известные ограничения поддержки импорта. Дополнительные сведения см. в разделе Сведения о миграции между продуктами GitHub.
- Хотя и не требуется, рекомендуется остановить работу во время рабочей миграции. Importer не поддерживает разностную миграцию, поэтому любые изменения, которые происходят во время миграции, не будут переноситься. Если вы решили не останавливать работу во время рабочей миграции, необходимо вручную перенести эти изменения.
- В исходных и конечных организациях необходимо либо владелец организации, либо предоставить роль миграции. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.
- Если вы используете GitHub Enterprise Server 3.8 или более поздней версии, чтобы настроить хранилище BLOB-объектов для экспортированных архивов, вам потребуется доступ к Консоль управления.
Шаг 1. Создание данных personal access token
- Создайте и запишите personal access token (classic), которая будет проходить проверку подлинности для целевой организации на GitHub Enterprise Cloud, убедившись, что маркер соответствует всем требованиям. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.
- Создайте и запишите personal access token, которая будет проходить проверку подлинности для исходной организации, убедившись, что этот маркер также соответствует всем одинаковым требованиям.
Шаг 2. Получение 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
идентификатор организации, который мы будем использовать на следующем шаге.
Шаг 3. Настройка хранилища BLOB-объектов
Так как многие экземпляры GitHub Enterprise Server сидят за брандмауэрами, для GitHub Enterprise Server версий 3.8 или более поздних версий мы используем хранилище BLOB-объектов в качестве промежуточного расположения для хранения данных, к которым могут получить доступ GitHub .
Сначала необходимо настроить хранилище BLOB-объектов с помощью поддерживаемого поставщика облачных служб, а затем настроить параметры в Консоль управления экземпляр GitHub Enterprise Server.
Note
Необходимо настроить только хранилище BLOB-объектов, если используется GitHub Enterprise Server версии 3.8 или более поздней. Если вы используете GitHub Enterprise Server версии 3.7 или более поздней, перейдите к шагу 4. Настройка источника миграции в GitHub Enterprise Cloud.
Хранилище BLOB-объектов требуется для переноса репозиториев с большим источником или метаданными Git. Если вы используете GitHub Enterprise Server версии 3.7 или более поздней, вы не сможете выполнять миграцию, в которой экспорт метаданных или источника Git превышает 2 ГБ. Чтобы выполнить эти миграции, обновите до GitHub Enterprise Server версии 3.8 или более поздней.
Настройка хранилища BLOB-объектов с помощью поддерживаемого поставщика облачных служб
GitHub CLI поддерживает следующие поставщики хранилища BLOB-объектов:
- Amazon Web Services (AWS) S3
- хранилище BLOB-объектов Azure
Настройка контейнера хранилища AWS S3
В AWS настройте контейнер S3. Дополнительные сведения см. в разделе "Создание контейнера " в документации ПО AWS.
Вам также потребуется ключ доступа AWS и секретный ключ со следующими разрешениями:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucketMultipartUploads",
"s3:AbortMultipartUpload",
"s3:ListBucket",
"s3:DeleteObject",
"s3:ListMultipartUploadParts"
],
"Resource": [
"arn:aws:s3:::github-migration-bucket",
"arn:aws:s3:::github-migration-bucket/*"
]
}
]
}
Note
GitHub Enterprise Importer не удаляет архив из AWS после завершения миграции. Чтобы сократить затраты на хранение, рекомендуется настроить автоматическое удаление архива через период времени. Дополнительные сведения см. в разделе Настройка конфигурации жизненного цикла в контейнере в документации AWS.
Настройка учетной записи Хранилище BLOB-объектов Azure
В Azure создайте учетную запись хранения и запишите строка подключения. Дополнительные сведения см. в разделе "Управление ключами доступа к учетной записи хранения" в Документация Майкрософт.
Note
GitHub Enterprise Importer не удаляет архив из Хранилище BLOB-объектов Azure после завершения миграции. Чтобы сократить затраты на хранение, рекомендуется настроить автоматическое удаление архива через период времени. Дополнительные сведения см. в статье "Оптимизация затрат путем автоматического управления жизненным циклом данных в Документация Майкрософт".
Настройка хранилища BLOB-объектов в Консоль управления экземпляр GitHub Enterprise Server
После настройки контейнера хранилища AWS S3 или учетной записи хранения Хранилище BLOB-объектов Azure настройте хранилище BLOB-объектов в Консоль управления экземпляр GitHub Enterprise Server. Дополнительные сведения о Консоль управлениясм. в статье администрирование экземпляра из консоли управления.
-
В учетной записи администратора GitHub Enterprise Server, в правом верхнем углу любой страницы щелкните .
-
Если вы еще не на странице "Администратор сайта" в левом верхнем углу щелкните "Администратор сайта". 1. На боковой панели " "Администратор сайта" щелкните Консоль управления.
-
Войдите в Консоль управления.
-
В верхней панели навигации** щелкните **"Параметры".
-
В разделе "Миграции" нажмите кнопку "Включить" GitHub Миграции.
-
При необходимости для импорта параметров хранилища, настроенных для GitHub Actions, выберите "Копировать параметры хранилища" из действий. Дополнительные сведения см. в статье "Включение действий GitHub с хранилищем BLOB-объектов Azure" и включение GitHub Actions с помощью хранилища Amazon S3.
Note
После копирования параметров хранилища может потребоваться обновить конфигурацию облачной учетной записи хранения, чтобы работать с GitHub Enterprise Importer. В частности, необходимо убедиться, что разрешены IP-адреса GitHub. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.
-
Если параметры хранилища не импортируются из GitHub Actions, выберите Хранилище BLOB-объектов Azure или Amazon S3 и заполните необходимые сведения.
Note
Если вы используете Amazon S3, необходимо задать URL-адрес службы AWS для стандартной конечной точки региона AWS, в котором находится контейнер. Например, если контейнер находится в регионе
eu-west-1
, будет указанhttps://s3.eu-west-1.amazonaws.com
URL-адрес службы AWS. Сеть экземпляра GitHub Enterprise Server должна разрешить доступ к этому узлу. Конечные точки шлюза не поддерживаются, напримерbucket.vpce-0e25b8cdd720f900e-argc85vg.s3.eu-west-1.vpce.amazonaws.com
. Дополнительные сведения о конечных точках шлюза см. в разделе "Конечные точки шлюза" для Amazon S3 в документации AWS. -
Щелкните " Тестировать параметры хранилища".
-
Нажмите кнопку Сохранить параметры.
Разрешение сетевого доступа
Если вы настроили правила брандмауэра в учетной записи хранения, убедитесь, что у вас есть доступ к диапазонам IP-адресов для назначения миграции. См . раздел AUTOTITLE.
Шаг 4. Настройка источника миграции в GitHub Enterprise Cloud
Вы можете настроить источник миграции с помощью createMigrationSource
запроса. Вам потребуется указать ownerId
идентификатор организации, собранный GetOrgInfo
из запроса.
Источник миграции — это ваша организация на GitHub Enterprise Server.
createMigrationSource
мутация
mutation createMigrationSource($name: String!, $url: String!, $ownerId: ID!) {
createMigrationSource(input: {name: $name, url: $url, ownerId: $ownerId, type: GITHUB_ARCHIVE}) {
migrationSource {
id
name
url
type
}
}
}
Note
Обязательно используйте GITHUB_ARCHIVE
для type
.
Переменная запроса | Description |
---|---|
name | Имя источника миграции. Это имя для собственной ссылки, поэтому можно использовать любую строку. |
ownerId | Идентификатор организации в GitHub Enterprise Cloud. |
url | URL-адрес для экземпляр GitHub Enterprise Server. Этот URL-адрес не должен быть доступен из GitHub Enterprise Cloud. |
createMigrationSource
ответ
{
"data": {
"createMigrationSource": {
"migrationSource": {
"id": "MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ",
"name": "GHES Source",
"url": "https://my-ghes-hostname.com",
"type": "GITHUB_ARCHIVE"
}
}
}
}
В этом примере MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ
— это идентификатор источника миграции, который мы будем использовать на следующем шаге.
Шаг 5. Создание архивов миграции на экземпляр GitHub Enterprise Server
Rest API будет использоваться для запуска двух "миграций" в GitHub Enterprise Server: один для создания архива источника Git репозитория и одного для создания архива метаданных репозитория (например, проблем и запросов на вытягивание).
Чтобы создать исходный архив Git, выполните POST
запрос https://HOSTNAME/api/v3/orgs/ORGANIZATION/migrations
, заменив HOSTNAME
имя узла экземпляр GitHub Enterprise Server, а также ORGANIZATION
имя входа вашей организации.
В тексте укажите один репозиторий, который требуется перенести. Запрос будет выглядеть примерно так:
POST /api/v3/orgs/acme-corp/migrations HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Content-Type: application/json
Host: github.acmecorp.net
{
"repositories": ["repository_to_migrate"],
"exclude_metadata": true
}
Чтобы создать архив метаданных, отправьте аналогичный запрос на тот же URL-адрес со следующим текстом:
{
"repositories": ["repository_to_migrate"],
"exclude_git_data": true,
"exclude_releases": false,
"exclude_owner_projects": true
}
Каждый из этих двух вызовов API возвращает ответ JSON, включая идентификатор запущенной миграции.
HTTP/1.1 201 Created
{
"id": 123,
// ...
}
Дополнительные сведения см. в разделе "Запуск миграции организации".
Создание архивов может занять некоторое время в зависимости от объема данных. Вы можете регулярно проверять состояние двух миграций с помощью API "Получить состояние миграции организации" до тех пор, пока state
миграция не изменится exported
.
GET /api/v3/orgs/acme-corp/migrations/123 HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Host: github.acmecorp.net
HTTP/1.1 200 OK
Content-Type: application/json
{
"id": 123,
"state": "exported",
// ...
}
Дополнительные сведения см. в разделе "Получение состояния миграции организации".
Note
Если миграция перемещается в failed
состояние, а не exported
состояние, попробуйте снова начать миграцию. Если миграция завершается сбоем, рекомендуется создать архивы, используя ghe-migrator
вместо API.
Выполните действия, описанные в разделе "Экспорт данных миграции из предприятия", добавив в миграцию только один репозиторий. В конце процесса у вас будет один архив миграции с источником и метаданными Git, и вы можете перейти к шагу 6 в этой статье.
state
После перехода exported
на миграцию можно получить URL-адрес миграции с помощью API загрузки архива миграции организации.
GET /api/v3/orgs/acme-corp/migrations/123/archive HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Host: github.acmecorp.net
HTTP/1.1 302 Found
Location: https://media.github.acmecorp.net/migrations/123/archive/cca2ebe9-7403-4ffa-9b6a-4c9e16c94410?token=AAAAABEWE7JP4H2HACKEGMTDOYRC6
API вернет 302 Found
ответ с заголовком Location
, перенаправляющимся на URL-адрес, в котором находится скачиваемый архив. Скачайте два файла: один для источника Git и один для метаданных.
Дополнительные сведения см. в разделе "Скачивание архива миграции организации".
После завершения обоих миграций и скачивания архивов можно перейти к следующему шагу.
Шаг 6. Отправка архивов миграции
Чтобы импортировать данные в GitHub Enterprise Cloud, необходимо передать оба архива для каждого репозитория (источник Git и метаданные) с компьютера в GitHub, используя наш API GraphQL.
Если вы используете GitHub Enterprise Server 3.7 или более поздней версии, необходимо сначала создать URL-адреса для архивов, доступных GitHub. Большинство клиентов предпочитают отправлять архивы в службу хранилища BLOB-объектов поставщика облачных служб, например Amazon S3 или Хранилище BLOB-объектов Azure, а затем создать короткий URL-адрес для каждого.
Если вы используете GitHub Enterprise Server 3.8 или более поздней версии, экземпляр отправляет архивы и создает URL-адреса для вас. Заголовок Location
на предыдущем шаге возвращает короткий URL-адрес.
Возможно, вам потребуется разрешить список данных . Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.
Шаг 7. Запуск миграции репозитория
При запуске миграции один репозиторий и его сопутствующие данные переносятся в новый репозиторий GitHub, который вы определяете.
Если вы хотите одновременно переместить несколько репозиториев из одной исходной организации, можно ставить в очередь несколько миграций. Одновременно можно выполнять до 5 миграций репозитория.
startRepositoryMigration
мутация
mutation startRepositoryMigration (
$sourceId: ID!,
$ownerId: ID!,
$repositoryName: String!,
$continueOnError: Boolean!,
$accessToken: String!,
$githubPat: String!,
$gitArchiveUrl: String!,
$metadataArchiveUrl: String!,
$sourceRepositoryUrl: URI!,
$targetRepoVisibility: String!
){
startRepositoryMigration( input: {
sourceId: $sourceId,
ownerId: $ownerId,
repositoryName: $repositoryName,
continueOnError: $continueOnError,
accessToken: $accessToken,
githubPat: $githubPat,
targetRepoVisibility: $targetRepoVisibility
gitArchiveUrl: $gitArchiveUrl,
metadataArchiveUrl: $metadataArchiveUrl,
sourceRepositoryUrl: $sourceRepositoryUrl,
}) {
repositoryMigration {
id
migrationSource {
id
name
type
}
sourceUrl
}
}
}
Переменная запроса | Description |
---|---|
sourceId | Источник миграции id вернулся из мутации create . |
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 для источника. |
target | Видимость нового репозитория. Должно быть private , public или internal . Если этот параметр не задан, репозиторий переносится как закрытый. |
gitArchiveUrl | URL-адрес для исходного архива Git { % variables.product.prodname_ghe_cloud %}. |
metadata | URL-адрес ,доступный для архива метаданных GitHub Enterprise Cloud. |
source | URL-адрес репозитория в экземпляре GitHub Enterprise Server. Это необходимо, но GitHub Enterprise Cloud не будет напрямую взаимодействовать с экземпляром GitHub Enterprise Server. |
Требования к personal access token см. в разделе Управление доступом к миграции между продуктами GitHub.
На следующем шаге вы будете использовать идентификатор миграции, возвращенный из startRepositoryMigration
изменения, чтобы проверка состояние миграции.
Шаг 8. Проверка состояния миграции
Чтобы обнаружить любые сбои миграции и убедиться, что миграция работает, можно проверка состояние миграции с помощью 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 , возвращаемая мутациейstart . |
Шаг 9. Проверка миграции и проверка журнала ошибок
Чтобы завершить миграцию, рекомендуется проверка проблему журнала миграции. Эта проблема создается на GitHub в целевом репозитории.
Наконец, мы рекомендуем просмотреть перенесенные репозитории для проверка звуки.