Сведения о миграции репозитория с помощью 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.com, чтобы определить, откуда выполняется миграция
- Для каждого репозитория, который требуется перенести, повторите эти действия.
- Использование REST API в экземпляр GitHub Enterprise Server для создания архивов миграции для репозитория
- Отправка архивов миграции в расположение, к которым можно получить доступ с помощью GitHub.com
- Запустите миграцию с помощью API GraphQL для GitHub.com, передавая URL-адреса архива
- Проверьте состояние миграции с помощью API GraphQL
- Проверка миграции и проверка журнала ошибок
Чтобы просмотреть инструкции по использованию API, используйте переключатель инструментов в верхней части страницы.
Чтобы просмотреть инструкции по использованию GitHub CLI, используйте переключатель инструментов в верхней части страницы.
Необходимые компоненты
- Настоятельно рекомендуется выполнить пробную версию миграции и завершить рабочую миграцию в ближайшее время. Дополнительные сведения о пробных запусках см. в разделе "Обзор миграции между продуктами GitHub".
- Убедитесь, что вы понимаете данные, которые будут перенесены, и известные ограничения поддержки импорта. Дополнительные сведения см. в разделе "Сведения о миграции между продуктами GitHub".
- Хотя и не требуется, рекомендуется остановить работу во время рабочей миграции. Importer не поддерживает разностную миграцию, поэтому любые изменения, которые происходят во время миграции, не будут переноситься. Если вы решили не останавливать работу во время рабочей миграции, необходимо вручную перенести эти изменения.
- В исходных и конечных организациях необходимо либо владелец организации, либо предоставить роль миграции. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.
- Если вы используете GitHub Enterprise Server 3.8 или более поздней версии, чтобы настроить хранилище BLOB-объектов для экспортированных архивов, вам потребуется доступ к Консоль управления.
Шаг 1. Создание данных personal access token
- Создайте и запишите personal access token, которая будет проходить проверку подлинности для целевой организации на 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.
Примечание. При использовании GitHub Enterprise Server версии 3.8 или более поздней необходимо настроить хранилище BLOB-объектов. Если вы используете 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/*"
]
}
]
}
Примечание. GitHub Enterprise Importer не удаляет архив из AWS после завершения миграции. Чтобы сократить затраты на хранение, рекомендуется настроить автоматическое удаление архива через период времени. Дополнительные сведения см. в разделе Настройка конфигурации жизненного цикла в контейнере в документации AWS.
Настройка учетной записи Хранилище BLOB-объектов Azure
В Azure создайте учетную запись хранения и запишите строка подключения. Дополнительные сведения см. в разделе "Управление ключами доступа к учетной записи хранения" в Документация Майкрософт.
Примечание. 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 с хранилищем Amazon S3".
Примечание. После копирования параметров хранилища может потребоваться обновить конфигурацию облачной учетной записи хранения, чтобы работать с GitHub Enterprise Importer. В частности, необходимо убедиться, что разрешены IP-адреса GitHub. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.
-
Если параметры хранилища не импортируются из GitHub Actions, выберите Хранилище BLOB-объектов Azure или Amazon S3 и заполните необходимые сведения.
Примечание. Если вы используете 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. -
Щелкните " Тестировать параметры хранилища".
-
Нажмите кнопку Сохранить параметры.
Шаг 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
}
}
}
Примечание. Обязательно используйте 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",
// ...
}
Дополнительные сведения см. в разделе "Получение состояния миграции организации".
Примечание. Если миграция перемещается в 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.com, используя наш API GraphQL.
Если вы используете GitHub Enterprise Server 3.7 или более поздней версии, необходимо сначала создать URL-адреса для архивов, доступных GitHub.com. Большинство клиентов предпочитают отправлять архивы в службу хранилища 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 вернулся из мутации 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 . Если этот параметр не задан, репозиторий переносится как закрытый. |
gitArchiveUrl | URL-адрес для исходного архива Git { % variables.product.prodname_ghe_cloud %}. |
metadataArchiveUrl | URL-адрес ,доступный для архива метаданных GitHub Enterprise Cloud. |
sourceRepositoryUrl | 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 , возвращаемая мутациейstartRepositoryMigration . |
Шаг 9. Проверка миграции и проверка журнала ошибок
Чтобы завершить миграцию, рекомендуется проверка проблему журнала миграции. Эта проблема создается на GitHub в целевом репозитории.
Наконец, мы рекомендуем просмотреть перенесенные репозитории для проверка звуки.
Шаг 1. Установка GEI extension of the GitHub CLI
Если это первая миграция, необходимо установить GEI extension of the GitHub CLI. Дополнительные сведения о GitHub CLIсм. в разделе "Сведения о GitHub CLI".
Кроме того, можно скачать автономный двоичный файл на странице выпусков для github/gh-gei
репозитория. Двоичный файл можно запускать напрямую без gh
префикса.
-
Установите GitHub CLI. Инструкции по установке для GitHub CLI см. в репозитории GitHub CLI.
Примечание. Вам нужна версия 2.4.0 или более позднюю версию GitHub CLI. Вы можете проверка версию, установленную
gh --version
с помощью команды. -
Установите GEI extension.
Shell gh extension install github/gh-gei
gh extension install github/gh-gei
В любое время, когда вам нужна помощь с GEI extension, можно использовать --help
флаг с помощью команды. Например, gh gei --help
перечислит все доступные команды и gh gei migrate-repo --help
отобразит список всех параметров, доступных для migrate-repo
команды.
Шаг 2. Обновление GEI extension of the GitHub CLI
Данные GEI extension обновляются еженедельно. Чтобы убедиться, что вы используете последнюю версию, обновите расширение.
gh extension upgrade github/gh-gei
Шаг 3. Задание переменных среды
Прежде чем использовать GEI extension для миграции на GitHub Enterprise Cloud, необходимо создать personal access tokens, которые могут получить доступ к исходным и целевым организациям, а затем задать personal access tokens в качестве переменных среды.
- Создайте и запишите personal access token, которая будет проходить проверку подлинности для целевой организации на GitHub Enterprise Cloud, убедившись, что маркер соответствует всем требованиям. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.
- Создайте и запишите personal access token, которая будет проходить проверку подлинности для исходной организации, убедившись, что этот маркер также соответствует всем одинаковым требованиям.
Шаг 4. Настройка хранилища BLOB-объектов
Так как многие экземпляры данных GitHub Enterprise Server сидят за брандмауэрами, мы используем хранилище BLOB-объектов в качестве промежуточного расположения для хранения данных, к которым могут получить доступ GitHub.
Сначала необходимо настроить хранилище BLOB-объектов с помощью поддерживаемого поставщика облачных служб. Затем необходимо настроить учетные данные для поставщика хранилища в Консоль управления или GitHub CLI.
Настройка хранилища 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/*"
]
}
]
}
Примечание. GitHub Enterprise Importer не удаляет архив из AWS после завершения миграции. Чтобы сократить затраты на хранение, рекомендуется настроить автоматическое удаление архива через период времени. Дополнительные сведения см. в разделе Настройка конфигурации жизненного цикла в контейнере в документации AWS.
Настройка учетной записи хранения Хранилище BLOB-объектов Azure
В Azure создайте учетную запись хранения и запишите строка подключения. Дополнительные сведения см. в разделе "Управление ключами доступа к учетной записи хранения" в Документация Майкрософт.
Примечание. GitHub Enterprise Importer не удаляет архив из Хранилище BLOB-объектов Azure после завершения миграции. Чтобы сократить затраты на хранение, рекомендуется настроить автоматическое удаление архива через период времени. Дополнительные сведения см. в статье "Оптимизация затрат путем автоматического управления жизненным циклом данных в Документация Майкрософт".
Настройка учетных данных хранилища BLOB-объектов
После настройки хранилища BLOB-объектов с поддерживаемым поставщиком облачных служб необходимо настроить учетные данные для поставщика хранилища в GitHub:
- Если вы используете GitHub Enterprise Server 3.8 или более поздней версии, настройте учетные данные в Консоль управления.
- Если вы используете GitHub Enterprise Server 3.7 или более поздней версии, настройте учетные данные в GitHub CLI.
Настройка хранилища BLOB-объектов в Консоль управления экземпляр GitHub Enterprise Server
Примечание. При использовании Консоль управления необходимо настроить только хранилище BLOB-объектов, если используется GitHub Enterprise Server 3.8 или более поздней версии. Если вы используете 3.7 или более поздней версии, настройте учетные данные в GitHub CLI вместо этого.
После настройки контейнера хранилища AWS S3 или учетной записи хранения Хранилище BLOB-объектов Azure настройте хранилище BLOB-объектов в Консоль управления экземпляр GitHub Enterprise Server. Дополнительные сведения о Консоль управлениясм. в статье "Администратор стеревание экземпляра из консоли управления".
-
В учетной записи администратора GitHub Enterprise Server, в правом верхнем углу любой страницы щелкните .
-
Если вы еще не на странице "Администратор сайта" в левом верхнем углу щелкните "Администратор сайта". 1. На боковой панели " "Администратор сайта" щелкните Консоль управления.
-
Войдите в Консоль управления.
-
В верхней панели навигации щелкните Параметры.
-
В разделе "Миграции" нажмите кнопку "Включить" GitHub Миграции.
-
При необходимости для импорта параметров хранилища, настроенных для GitHub Actions, выберите "Копировать служба хранилища" из действий. Дополнительные сведения см. в статье "Включение действий GitHub с хранилищем BLOB-объектов Azure" и "Включение действий GitHub с хранилищем Amazon S3".
Примечание. После копирования параметров хранилища может потребоваться обновить конфигурацию облачной учетной записи хранения, чтобы работать с GitHub Enterprise Importer. В частности, необходимо убедиться, что разрешены IP-адреса GitHub. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.
-
Если параметры хранилища не импортируются из GitHub Actions, выберите Хранилище BLOB-объектов Azure или Amazon S3 и заполните необходимые сведения.
Примечание. Если вы используете 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. -
Щелкните " Тестировать параметры хранилища".
-
Нажмите кнопку Сохранить параметры.
Настройка учетных данных хранилища BLOB-объектов в GitHub CLI
Примечание. При использовании GitHub Enterprise Server или более поздней версии необходимо настроить учетные данные хранилища BLOB-объектов в GitHub CLI. Если вы используете 3.8 или более поздней версии, настройте хранилище BLOB-объектов в Консоль управления вместо этого.
Если вы настроите учетные данные хранилища BLOB-объектов в GitHub CLI, вы не сможете выполнить миграцию, в которой экспорт метаданных или источника Git превышает 2 ГБ. Чтобы выполнить эти миграции, обновите до GitHub Enterprise Server 3,8 или более поздней версии.
Настройка учетных данных AWS S3 в GitHub CLI
Когда вы будете готовы к миграции, вам потребуется предоставить учетные данные AWS в GitHub CLI: регион, ключ доступа, секретный ключ и маркер сеанса (при необходимости). Их можно передать в качестве аргументов или задать переменные среды, называемые AWS_REGION
, и AWS_SESSION_TOKEN``AWS_ACCESS_KEY_ID``AWS_SECRET_ACCESS_KEY
.
Кроме того, необходимо передать имя контейнера S3 с помощью аргумента --aws-bucket-name
.
Настройка учетных данных учетной записи Хранилище BLOB-объектов Azure в GitHub CLI
Когда вы будете готовы выполнить миграцию, вы можете передать строка подключения в GitHub CLI в качестве аргумента или передать его с помощью переменной AZURE_STORAGE_CONNECTION_STRING
среды.
Шаг 5. Создание скрипта миграции
Если вы хотите перенести несколько репозиториев в 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)чтобы запустить его.
Если вы хотите перенести один репозиторий, перейдите к следующему шагу.
Создание скрипта миграции
Этот шаг необходимо выполнить с компьютера, который может получить доступ к API для экземпляр GitHub Enterprise Server. Если вы можете получить доступ к экземпляру из браузера, компьютер имеет правильный доступ.
Чтобы создать скрипт миграции, выполните gh gei generate-script
команду.
Для GitHub Enterprise Server 3.8 или более поздней версии или если вы используете 3.7 или более поздней версии с Хранилище BLOB-объектов Azure, используйте следующие флаги:
gh gei generate-script --github-source-org SOURCE \ --github-target-org DESTINATION \ --output FILENAME \ --ghes-api-url GHES-API-URL
gh gei generate-script --github-source-org SOURCE \
--github-target-org DESTINATION \
--output FILENAME \
--ghes-api-url GHES-API-URL
Если вы используете GitHub Enterprise Server 3.7 или ниже с AWS S3, используйте следующие флаги:
gh gei generate-script --github-source-org SOURCE \ --github-target-org DESTINATION \ --output FILENAME \ --ghes-api-url GHES-API-URL \ --aws-bucket-name AWS-BUCKET-NAME
gh gei generate-script --github-source-org SOURCE \
--github-target-org DESTINATION \
--output FILENAME \
--ghes-api-url GHES-API-URL \
--aws-bucket-name AWS-BUCKET-NAME
Если экземпляр GitHub Enterprise Server использует самозаверяющий или недопустимый SSL-сертификат, используйте --no-ssl-verify
флаг. При использовании этого флага GitHub CLI пропустит проверку SSL-сертификата только при извлечении данных из экземпляра. Все остальные вызовы будут проверять SSL.
Если вы хотите, чтобы скрипт скачал журнал миграции для каждого перенесенного репозитория, добавьте --download-migration-logs
флаг. Дополнительные сведения о журналах миграции см. в разделе "Доступ к журналам миграции для GitHub Enterprise Importer".
Замените заполнители в приведенной выше команде следующими значениями.
Заполнитель | Значение |
---|---|
ИСТОЧНИК | Имя исходной организации |
НАЗНАЧЕНИЕ | Имя целевой организации |
FILENAME | Имя файла для результирующего скрипта миграции Если вы используете терминал, используйте .ps1 расширение файла в качестве созданного скрипта, чтобы запустить PowerShell. Вы можете установить PowerShell для Mac или Linux. |
GHES-API-URL | URL-адрес для API экземпляр GitHub Enterprise Server, например https://myghes.com/api/v3 |
AWS-BUCKET-NAME | Имя контейнера для контейнера AWS S3 |
Просмотр скрипта миграции
После создания скрипта просмотрите файл и, при необходимости, измените скрипт.
- Если есть какие-либо репозитории, которые вы не хотите перенести, удалить или закомментировать соответствующие строки.
- Если в целевой организации есть другое имя репозиториев, обновите значение соответствующего
--target-repo
флага.
Примечание. Если в репозитории имеется более 10 ГБ данных о выпусках, выпуски не могут быть перенесены. --skip-releases
Используйте флаг для переноса репозитория без выпусков.
Если вы скачали GEI как автономный двоичный файл, а не как расширение для GitHub CLI, необходимо обновить созданный скрипт, чтобы запустить двоичный файл вместо gh gei
него.
Шаг 6. Миграция репозиториев
При переносе репозиториев GEI extension of the GitHub CLI выполняет следующие действия:
- Подключается к экземпляр GitHub Enterprise Server и создает два архива миграции для каждого репозитория, один для источника Git и один для метаданных.
- Отправляет архивы миграции в выбранный поставщик хранилища BLOB-объектов.
- Начинает миграцию в GitHub Enterprise Cloud, используя URL-адреса архивов, хранящихся в поставщике хранилища BLOB-объектов.
- Удаляет архив миграции с локального компьютера
Перенос нескольких репозиториев
Если вы переносите данные GitHub Enterprise Server 3.7 или более ранних версий, перед запуском скрипта необходимо задать дополнительные переменные среды для проверки подлинности в поставщике хранилища BLOB-объектов.
-
Для Хранилище BLOB-объектов Azure задайте
AZURE_STORAGE_CONNECTION_STRING
строка подключения для учетной записи хранения Azure.Поддерживаются только строка подключения с помощью ключей доступа к учетной записи хранения. строки Подключение ion, использующие подписанные URL-адреса (SAS), не поддерживаются. Дополнительные сведения о ключах доступа к учетной записи хранения см. в статье "Управление ключами доступа к учетной записи хранения" в документации Azure.
-
Для AWS S3 задайте следующие переменные среды.
AWS_ACCESS_KEY
: ключ доступа для контейнераAWS_SECRET_KEY
: секретный ключ для контейнераAWS_REGION
: регион AWS, в котором находится контейнерAWS_SESSION_TOKEN
: маркер сеанса, если вы используете временные учетные данные AWS (см. сведения об использовании временных учетных данных с ресурсами AWS в документации AWS).
Перенос одного репозитория
Этот шаг необходимо выполнить с компьютера, который может получить доступ к API для экземпляр GitHub Enterprise Server. Если вы можете получить доступ к экземпляру из браузера, компьютер имеет правильный доступ.
Если вы используете GitHub Enterprise Server 3.8 или более поздней версии, используйте следующие флаги:
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME --ghes-api-url GHES-API-URL
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME --ghes-api-url GHES-API-URL
Если вы переносите данные GitHub Enterprise Server 3.7 или более ранних версий и используете Хранилище BLOB-объектов Azure в качестве поставщика хранилища BLOB-объектов, используйте следующие флаги для проверки подлинности:
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \ --ghes-api-url GHES-API-URL --azure-storage-connection-string "AZURE_STORAGE_CONNECTION_STRING"
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \
--ghes-api-url GHES-API-URL --azure-storage-connection-string "AZURE_STORAGE_CONNECTION_STRING"
Если вы переносите данные GitHub Enterprise Server 3.7 или более ранних версий и используете Amazon S3 в качестве поставщика хранилища BLOB-объектов, используйте следующие флаги для проверки подлинности:
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \ --ghes-api-url GHES-API-URL --aws-bucket-name "AWS-BUCKET-NAME"
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \
--ghes-api-url GHES-API-URL --aws-bucket-name "AWS-BUCKET-NAME"
Если экземпляр GitHub Enterprise Server использует самозаверяющий или недопустимый SSL-сертификат, используйте --no-ssl-verify
флаг. При использовании этого флага GitHub CLI пропустит проверку SSL-сертификата только при извлечении данных из экземпляра. Все остальные вызовы будут проверять SSL.
Примечание. Если в репозитории имеется более 10 ГБ данных о выпусках, выпуски не могут быть перенесены. --skip-releases
Используйте флаг для переноса репозитория без выпусков.
GHES-API-URL | URL-адрес для API экземпляр GitHub Enterprise Server, например https://myghes.com/api/v3
AZURE_STORAGE_CONNECTION_STRING | Строка подключения для учетной записи хранения Azure.
Обязательно процитировать строка подключения, содержащий символы, которые, скорее всего, будут интерпретированы оболочкой.
AWS-BUCKET-NAME | Имя контейнера для контейнера AWS S3
Если вы хотите отменить миграцию, используйте abort-migration
команду, заменив идентификатор MIGRATION-ID возвращенным идентификатором migrate-repo
.
gh gei abort-migration --migration-id MIGRATION-ID
gh gei abort-migration --migration-id MIGRATION-ID
Шаг 7. Проверка миграции и проверка журнала ошибок
По завершении миграции рекомендуется просмотреть журнал миграции. Дополнительные сведения см. в разделе Доступ к журналам миграции для GitHub Enterprise Importer.
Рекомендуется просмотреть перенесенные репозитории для проверки звука.
После завершения миграции рекомендуется удалить архивы из контейнера хранилища. Если вы планируете выполнить дополнительные миграции, удалите архив, помещенный в контейнер хранилища, с помощью ADO2GH extension. Если вы закончите перенос, вы можете удалить весь контейнер.