Перенос данных на GitHub Enterprise Server

Подготовка перенесенных данных

1. С помощью команды scp скопируйте архив миграции, созданный из исходного экземпляра или организации, в целевой объект GitHub Enterprise Server:

   scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/
   

2. SSH в целевом экземпляре GitHub Enterprise Server. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

   ssh -p 122 admin@HOSTNAME
   

3. Используйте команду ghe-migrator prepare, чтобы подготовить архив для импорта в целевой экземпляр и создать новый уникальный идентификатор миграции, который будет использоваться в последующих шагах:

   ghe-migrator prepare /home/admin/MIGRATION-GUID.tar.gz
   

   • Чтобы начать новую попытку импорта, запустите ghe-migrator prepare еще раз и получите новый уникальный идентификатор миграции.
   • Чтобы указать, где следует выполнить подготовку файлов миграции, добавьте команду с --staging-path=/full/staging/path. По умолчанию — /data/user/tmp.

Создание списка конфликтов миграции

1. Используя команду ghe-migrator conflicts с уникальным идентификатором миграции, создайте файл conflicts.csv:

   ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv
   

   • Если не сообщается о конфликтах, можно безопасно импортировать данные.

2. При наличии конфликтов с помощью команды scp скопируйте conflicts.csv на локальный компьютер:

   scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop
   

3. Перейдите к разделу Устранение конфликтов миграции или настройка пользовательских сопоставлений.

Просмотр конфликтов миграции

1. Откройте conflicts.csv с помощью текстового редактора или программного обеспечения для работы с электронными таблицами, совместимого с форматом CSV.
2. Руководствуясь приведенными ниже примерами и справочными таблицами, просмотрите файл conflicts.csv, чтобы убедиться, что при импорте будут выполнены соответствующие действия.

Файл conflicts.csv содержит карту миграции конфликтов и рекомендуемые действия. Карта миграции содержит сведения о том, какие данные переносятся из источника и как данные будут применены к целевому объекту.

model_name	source_url	target_url	recommended_action
user	https://example-gh.source/octocat	https://example-gh.target/octocat	map
organization	https://example-gh.source/octo-org	https://example-gh.target/octo-org	map
repository	https://example-gh.source/octo-org/widgets	https://example-gh.target/octo-org/widgets	rename
team	https://example-gh.source/orgs/octo-org/teams/admins	https://example-gh.target/orgs/octo-org/teams/admins	merge
project	https://example-gh.source/octo-org/widgets/projects/1	https://example-gh.target/octo-org/projects/1	merge

Каждая строка в conflicts.csv предоставляет следующие сведения:

Имя	Описание
model_name	Тип изменяемых данных.
source_url	Исходный URL-адрес данных.
target_url	Ожидаемый целевой URL-адрес данных.
recommended_action	Предпочтительное действие, которое выполнит ghe-migrator при импорте данных.

Возможные сопоставления для каждого типа записи

Существует несколько различных действий сопоставления, которые ghe-migrator может выполнить при передаче данных:

action	Description	Применимые модели
import	(по умолчанию) Данные из источника импортируются в целевой объект.	Все типы записей
map	Вместо создания новой модели на основе исходных данных используется существующая запись в целевом объекте. Полезно для импорта репозитория в существующую организацию или сопоставления удостоверений пользователей в целевом объекте с удостоверениями пользователей в источнике.	Пользователи, организации, проекты
rename	Данные из источника переименовываются, а затем копируются в целевой объект.	Пользователи, организации, репозитории, проекты
map_or_rename	Если целевой объект существует, данные сопоставляются с ним. В противном случае импортированная модель переименовывается.	Пользователи
merge	Данные из источника совмещаются с существующими данными в целевом объекте.	Teams, проекты

Мы настоятельно рекомендуем просмотреть файл conflicts.csv и использовать ghe-migrator audit, чтобы убедиться, что выполняются нужные действия. Если все выглядит хорошо, можно продолжить.

Устранение конфликтов миграции или настройка пользовательских сопоставлений

Если вы считаете, что ghe-migrator выполнит неправильное изменение, можно внести исправления, изменив данные в conflicts.csv. Вы можете внести изменения в любую из строк в conflicts.csv.

Например, предположим, что octocat пользователь из источника сопоставляется с octocat целевым объектом.

model_name	source_url	target_url	recommended_action
user	https://example-gh.source/octocat	https://example-gh.target/octocat	map

Вы можете сопоставить пользователя с другим пользователем в целевом объекте. Предположим, вы знаете, что octocat на самом деле должен быть monalisa в целевом объекте. Столбец можно изменить target_url в conflicts.csv , чтобы ссылаться monalisaна .

model_name	source_url	target_url	recommended_action
user	https://example-gh.source/octocat	https://example-gh.target/monalisa	map

В качестве другого примера, если вы хотите переименовать репозиторий в целевой экземпляр, измените его target_url на octo-org/amazing-widgets и на recommend_action rename.octo-org/widgets octo-org/amazing-widgets

model_name	source_url	target_url	recommended_action
repository	https://example-gh.source/octo-org/widgets	https://example-gh.target/octo-org/amazing-widgets	rename

Добавление пользовательских сопоставлений

Распространенный сценарий во время миграции заключается в том, что у имена перенесенных пользователей в целевом объекте будут отличаться от тех, что назначены им в источнике.

Имея список имен пользователей в источнике и список имен пользователей в целевом объекте, вы можете создать CSV-файл с пользовательскими сопоставлениями, а затем применить его, чтобы имена пользователей и их данные были правильно сопоставлены после миграции.

Вы можете быстро создать CSV-файл пользователей, которые переносятся. Он необходим для применения пользовательских сопоставлений с помощью команды ghe-migrator audit:

ghe-migrator audit -m user -g MIGRATION-GUID > users.csv

Теперь вы можете изменить этот CSV-файл и ввести новый URL-адрес для каждого пользователя, которого вы хотите сопоставить или переименовать, а затем обновить четвертый столбец, чтобы выполнить map или rename.

Например, чтобы переименовать пользователя octocat в monalisa в целевом объекте https://example-gh.target создайте строку со следующим содержимым:

model_name	source_url	target_url	state
user	https://example-gh.source/octocat	https://example-gh.target/monalisa	rename

Один и тот же процесс можно использовать для создания сопоставлений для каждой записи, поддерживающей пользовательские сопоставления. Дополнительные сведения см. в таблице возможных сопоставлений записей.

Применение измененных данных миграции

1. После внесения изменений используйте команду scp для применения измененного файла conflicts.csv (или любого другого файла .csv сопоставлений в правильном формате) к целевому экземпляру:

   scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/
   

2. Повторно сопоставите данные миграции с помощью команды ghe-migrator map, передав путь к измененным файлу .csv и уникальному идентификатору миграции:

   ghe-migrator map -i conflicts.csv  -g MIGRATION-GUID
   

3. Если команда ghe-migrator map -i conflicts.csv -g MIGRATION-GUID сообщит, что конфликты по-прежнему существуют, снова выполните процесс разрешения конфликтов миграции.

Применение импортированных данных к GitHub Enterprise Server

1. SSH в целевом экземпляре GitHub Enterprise Server. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

   ssh -p 122 admin@HOSTNAME
   

2. С помощью команды ghe-migrator import запустите процесс импорта. Что вам понадобится:

   • GUID миграции. Дополнительные сведения см. в разделе "Подготовка перенесенных данных для импорта в GitHub Enterprise Server".
   • Данные personal access token для проверки подлинности. Используемые данные personal access token используются только для проверки подлинности в качестве администратора сайта и не требуют каких-либо определенных областей или разрешений. Дополнительные сведения см. в разделе Управление личными маркерами доступа.

   $ ghe-migrator import /home/admin/MIGRATION-GUID.tar.gz -g MIGRATION-GUID -u USERNAME -p TOKEN
   
   > Starting GitHub::Migrator
   > Import 100% complete /
   

   • Чтобы указать, где следует выполнить подготовку файлов миграции, добавьте команду с --staging-path=/full/staging/path. По умолчанию — /data/user/tmp.

Проверка данных миграции

По умолчанию ghe-migrator audit возвращает каждую запись. Кроме того, это позволяет фильтровать записи по следующим критериям:

• Типы записей.
• Состояние записей.

Типы записей соответствуют тем, которые находятся в перенесенных данных.

Фильтры типов записей

Тип записи	Имя фильтра
Пользователи	user
Организации	organization
Репозитории	repository
Teams	team
Milestones	milestone
Проекты (классическая модель)	project
Проблемы	issue
Комментарии к проблеме	issue_comment
Запросы на включение внесенных изменений	pull_request
Проверки запросов на включение изменений	pull_request_review
Комментарии к фиксации	commit_comment
Комментарии к проверке запроса на вытягивание	pull_request_review_comment
Выпуски	release
Действия, выполняемые для запросов на вытягивание или проблем	issue_event
Защищенные ветви	protected_branch

Фильтры состояния записи

Состояние записи	Description
export	Запись будет экспортирована.
import	Запись будет импортирована.
map	Запись будет сопоставлена.
rename	Запись будет сопоставлена.
merge	Запись будет объединена.
exported	Запись экспортирована успешно.
imported	Запись импортирована успешно.
mapped	Запись сопоставлена успешно.
renamed	Запись переименована успешно.
merged	Запись объединена успешно.
failed_export	Не удалось экспортировать запись.
failed_import	Не удалось импортировать запись.
failed_map	Не удалось сопоставить запись.
failed_rename	Не удалось переименовать запись.
failed_merge	Не удалось объединить запись.

Фильтрация записей аудита

С помощью команды ghe-migrator audit можно отфильтровать данные по типу записи с помощью флага -m. Аналогичным образом можно отфильтровать состояние импорта с помощью флага -s. Эта команда выглядит следующим образом:

ghe-migrator audit -m RECORD_TYPE -s STATE -g MIGRATION-GUID

Например, чтобы просмотреть каждую успешно импортированную организацию и команду, необходимо ввести следующее:

$ ghe-migrator audit -m organization,team -s mapped,renamed -g MIGRATION-GUID
> model_name,source_url,target_url,state
> organization,https://gh.source/octo-org/,https://ghe.target/octo-org/,renamed

Настоятельно рекомендуется проводить аудит каждой операции импорта, завершившейся сбоем. Для этого введите:

$ ghe-migrator audit -s failed_import,failed_map,failed_rename,failed_merge -g MIGRATION-GUID
> model_name,source_url,target_url,state
> user,https://gh.source/octocat,https://gh.target/octocat,failed
> repository,https://gh.source/octo-org/octo-project,https://ghe.target/octo-org/octo-project,failed

Если у вас возникли проблемы с неудачными импортами, обратитесь к нам, перейдя по адресу Поддержка GitHub Enterprise.

Завершение импорта в GitHub Enterprise Server

После применения миграции к целевому экземпляру и проверки миграции следует разблокировать репозитории и удалить их из источника. Перед удалением исходных данных рекомендуется подождать около двух недель, чтобы убедиться, что все работает должным образом.

Разблокировка репозиториев на целевом экземпляре

1. SSH в ваш экземпляр GitHub Enterprise Server. Если экземпляр состоит из нескольких узлов, например, если настроен высокий уровень доступности или георепликация, передача осуществляется по SSH в основной узел. При использовании кластера можно использовать для передачи по SSH в любой узел. Замените HOSTNAME именем узла для экземпляра, именем узла или IP-адресом узла. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

   Shell

   ssh -p 122 admin@HOSTNAME
   

2. Разблокируйте все импортированные репозитории с помощью команды ghe-migrator unlock. Вам потребуется GUID миграции:

$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project

Разблокировка репозиториев в источнике

После завершения миграции необходимо разблокировать репозитории в источнике.

Разблокировка репозиториев из организации в GitHub.com

Чтобы разблокировать репозитории в организации GitHub.com, отправьте запрос DELETE в конечную точку разблокировки миграции. Что вам понадобится:

• Маркер доступа для проверки подлинности
• Уникальный id миграции
• Имя репозитория для разблокировки

curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  -H "Accept: application/vnd.github.wyandotte-preview+json" \
  https://api.github.com/orgs/ORG-NAME/migrations/ID/repos/REPO_NAME/lock

Удаление репозиториев из организации в GitHub.com

После разблокировки репозиториев организации GitHub.com следует удалить каждый репозиторий, перенесенный ранее с помощью конечной точки удаления репозитория. Вам потребуется маркер доступа для проверки подлинности

curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  https://api.github.com/repos/ORG-NAME/REPO_NAME

Разблокировка репозиториев из экземпляра GitHub Enterprise Server

1. SSH в ваш экземпляр GitHub Enterprise Server. Если экземпляр состоит из нескольких узлов, например, если настроен высокий уровень доступности или георепликация, передача осуществляется по SSH в основной узел. При использовании кластера можно использовать для передачи по SSH в любой узел. Замените HOSTNAME именем узла для экземпляра, именем узла или IP-адресом узла. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

   Shell

   ssh -p 122 admin@HOSTNAME
   

2. Разблокируйте все импортированные репозитории с помощью команды ghe-migrator unlock. Вам потребуется GUID миграции:

$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project