Подготовка перенесенных данных
-
Используя команду
scp, скопируйте архив миграции, сгенерированный из исходного экземпляра или организации, на целевую GitHub Enterprise Server цель:scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/ -
SSH в целевом экземпляре GitHub Enterprise Server. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).
ssh -p 122 admin@HOSTNAME -
Убедитесь, что архив миграции имеет достаточные разрешения на чтение.
chmod 644 /home/admin/MIGRATION-GUID.tar.gz -
Используйте команду
ghe-migrator prepare, чтобы подготовить архив для импорта в целевой экземпляр и создать новый уникальный идентификатор миграции, который будет использоваться в последующих шагах:ghe-migrator prepare /home/admin/MIGRATION-GUID.tar.gz- Чтобы начать новую попытку импорта, запустите
ghe-migrator prepareеще раз и получите новый уникальный идентификатор миграции. - Чтобы указать, где следует выполнить подготовку файлов миграции, добавьте команду с
--staging-path=/full/staging/path. По умолчанию —/data/user/tmp.
- Чтобы начать новую попытку импорта, запустите
Создание списка конфликтов миграции
-
Используя команду
ghe-migrator conflictsс уникальным идентификатором миграции, создайте файл conflicts.csv:ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv- Если не сообщается о конфликтах, можно безопасно импортировать данные.
-
При наличии конфликтов с помощью команды
scpскопируйте conflicts.csv на локальный компьютер:scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop -
Продолжайте устранять конфликты миграции или настраивать пользовательские сопоставления.
Просмотр конфликтов миграции
- Откройте conflicts.csv с помощью текстового редактора или программного обеспечения для работы с электронными таблицами, совместимого с форматом CSV.
- Руководствуясь приведенными ниже примерами и справочными таблицами, просмотрите файл conflicts.csv, чтобы убедиться, что при импорте будут выполнены соответствующие действия.
Файл conflicts.csv содержит карту миграции конфликтов и рекомендуемые действия. Карта миграции содержит сведения о том, какие данные переносятся из источника и как данные будут применены к целевому объекту.
model_name | source_url | target_url | recommended_action |
|---|---|---|---|
user | https:/ | https:/ | map |
organization | https:/ | https:/ | map |
repository | https:/ | https:/ | rename |
team | https:/ | https:/ | merge |
Каждая строка в conflicts.csv предоставляет следующие сведения:
| Имя | Описание |
|---|---|
model_name | Тип изменяемых данных. |
source_url | Исходный URL-адрес данных. |
target_url | Ожидаемый целевой URL-адрес данных. |
recommended_action | Предпочтительное действие, которое выполнит ghe-migrator при импорте данных. |
Возможные сопоставления для каждого типа записи
Существует несколько различных действий сопоставления, которые ghe-migrator может выполнить при передаче данных:
action | Описание | Применимые модели |
|---|---|---|
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:/ | https:/ | map |
Вы можете сопоставить пользователя с другим пользователем в целевом объекте. Предположим, вы знаете, что octocat на самом деле должен быть monalisa в целевом объекте. Столбец можно изменить target_url в conflicts.csv , чтобы ссылаться monalisaна .
model_name | source_url | target_url | recommended_action |
|---|---|---|---|
user | https:/ | https:/ | map |
В качестве другого примера, если вы хотите переименовать репозиторий в целевой экземпляр, измените его octo-org/widgets на octo-org/amazing-widgets и на target_url``octo-org/amazing-widgets.recommend_action``rename
model_name | source_url | target_url | recommended_action |
|---|---|---|---|
repository | https:/ | https:/ | 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:/ | https:/ | rename |
Один и тот же процесс можно использовать для создания сопоставлений для каждой записи, поддерживающей пользовательские сопоставления. Дополнительные сведения см. в таблице возможных сопоставлений записей.
Применение измененных данных миграции
-
После внесения изменений используйте команду
scpдля применения измененного файла conflicts.csv (или любого другого файла .csv сопоставлений в правильном формате) к целевому экземпляру:scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/ -
Повторно сопоставите данные миграции с помощью команды
ghe-migrator map, передав путь к измененным файлу .csv и уникальному идентификатору миграции:ghe-migrator map -i conflicts.csv -g MIGRATION-GUID -
Если команда
ghe-migrator map -i conflicts.csv -g MIGRATION-GUIDсообщит, что конфликты по-прежнему существуют, снова выполните процесс разрешения конфликтов миграции.
Применение импортированных данных на GitHub Enterprise Server
-
SSH в целевом экземпляре GitHub Enterprise Server. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).
ssh -p 122 admin@HOSTNAME -
С помощью команды
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 |
| Проблемы | issue |
| Комментарии к проблеме | issue_comment |
| Запросы на включение внесенных изменений | pull_request |
| Проверки запросов на включение изменений | pull_request_ |
| Комментарии к фиксации | commit_comment |
| Комментарии к проверке запроса на вытягивание | pull_request_ |
| Выпуски | release |
| Действия, выполняемые для запросов на вытягивание или проблем | issue_event |
| Защищенные ветви | protected_branch |
Фильтры состояния записи
| Состояние записи | Описание |
|---|---|
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
После применения миграции к целевому экземпляру и проверки миграции следует разблокировать репозитории и удалить их из источника. Перед удалением исходных данных рекомендуется подождать около двух недель, чтобы убедиться, что все работает должным образом.
Разблокировка репозиториев на целевом экземпляре
-
SSH в ваш экземпляр GitHub Enterprise Server. Если экземпляр состоит из нескольких узлов, например, если настроен высокий уровень доступности или георепликация, передача осуществляется по SSH в основной узел. При использовании кластера можно использовать для передачи по SSH в любой узел. Замените HOSTNAME именем узла для экземпляра, именем узла или IP-адресом узла. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).
Shell ssh -p 122 admin@HOSTNAME
ssh -p 122 admin@HOSTNAME -
Разблокируйте все импортированные репозитории с помощью команды
ghe-migrator unlock. Вам потребуется GUID миграции:
$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project
Предупреждение
Если в вашем репозитории есть GitHub Actions рабочие процессы, использующие триггер schedule , рабочие процессы не будут запускаться автоматически после импорта. Чтобы снова запустить запланированные рабочие процессы, отправьте фиксацию в репозиторий. Дополнительные сведения см. в разделе События, инициирующие рабочие процессы.
Разблокировка репозиториев в источнике
После завершения миграции необходимо разблокировать репозитории в источнике.
Разблокировка репозиториев из организации на 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
-
SSH в ваш экземпляр GitHub Enterprise Server. Если экземпляр состоит из нескольких узлов, например, если настроен высокий уровень доступности или георепликация, передача осуществляется по SSH в основной узел. При использовании кластера можно использовать для передачи по SSH в любой узел. Замените HOSTNAME именем узла для экземпляра, именем узла или IP-адресом узла. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).
Shell ssh -p 122 admin@HOSTNAME
ssh -p 122 admin@HOSTNAME -
Разблокируйте все импортированные репозитории с помощью команды
ghe-migrator unlock. Вам потребуется GUID миграции:
$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project