Подготовка перенесенных данных
-
С помощью команды скопируйте архив миграции, созданный из исходного экземпляра или организации, в целевой объект 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 /home/admin/MIGRATION-GUID.tar.gz- Чтобы начать новую попытку импорта, запустите еще раз и получите новый уникальный идентификатор миграции.
- Чтобы указать, где следует выполнить подготовку файлов миграции, добавьте команду с
--staging-path=/full/staging/path. По умолчанию —/data/user/tmp.
Создание списка конфликтов миграции
-
Используя команду с уникальным идентификатором миграции, создайте файл conflicts.csv:
ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv- Если не сообщается о конфликтах, можно безопасно импортировать данные.
-
При наличии конфликтов с помощью команды скопируйте 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://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 | Предпочтительное действие, которое выполнит при импорте данных. |
Возможные сопоставления для каждого типа записи
Существует несколько различных действий сопоставления, которые может выполнить при передаче данных:
action | Описание | Применимые модели |
|---|---|---|
import | (по умолчанию) Данные из источника импортируются в целевой объект. | Все типы записей |
map | Вместо создания новой модели на основе исходных данных используется существующая запись в целевом объекте. Полезно для импорта репозитория в существующую организацию или сопоставления удостоверений пользователей в целевом объекте с удостоверениями пользователей в источнике. | Пользователи, организации, проекты |
rename | Данные из источника переименовываются, а затем копируются в целевой объект. | Пользователи, организации, репозитории, проекты |
map_or_rename | Если целевой объект существует, данные сопоставляются с ним. В противном случае импортированная модель переименовывается. | Пользователи |
merge | Данные из источника совмещаются с существующими данными в целевом объекте. | Teams, проекты |
Мы настоятельно рекомендуем просмотреть файл conflicts.csv и использовать , чтобы убедиться, что выполняются нужные действия. Если все выглядит хорошо, можно продолжить.
Устранение конфликтов миграции или настройка пользовательских сопоставлений
Если вы считаете, что выполнит неправильное изменение, можно внести исправления, изменив данные в conflicts.csv. Вы можете внести изменения в любую из строк в conflicts.csv.
Например, предположим, что пользователь из источника сопоставляется с целевым объектом.
model_name | source_url | target_url | recommended_action |
|---|---|---|---|
user | https://example-gh.source/octocat | https://example-gh.target/octocat | map |
Вы можете сопоставить пользователя с другим пользователем в целевом объекте. Предположим, вы знаете, что на самом деле должен быть в целевом объекте. Столбец можно изменить в conflicts.csv , чтобы ссылаться на .
model_name | source_url | target_url | recommended_action |
|---|---|---|---|
user | https://example-gh.source/octocat | https://example-gh.target/monalisa | map |
В качестве другого примера, если вы хотите переименовать репозиторий в целевой экземпляр, измените его на и на .
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 -m user -g MIGRATION-GUID > users.csv
Теперь вы можете изменить этот CSV-файл и ввести новый URL-адрес для каждого пользователя, которого вы хотите сопоставить или переименовать, а затем обновить четвертый столбец, чтобы выполнить или .
Например, чтобы переименовать пользователя в в целевом объекте создайте строку со следующим содержимым:
model_name | source_url | target_url | state |
|---|---|---|---|
user | https://example-gh.source/octocat | https://example-gh.target/monalisa | rename |
Один и тот же процесс можно использовать для создания сопоставлений для каждой записи, поддерживающей пользовательские сопоставления. Дополнительные сведения см. в таблице возможных сопоставлений записей.
Применение измененных данных миграции
-
После внесения изменений используйте команду для применения измененного файла conflicts.csv (или любого другого файла .csv сопоставлений в правильном формате) к целевому экземпляру:
scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/ -
Повторно сопоставите данные миграции с помощью команды , передав путь к измененным файлу .csv и уникальному идентификатору миграции:
ghe-migrator map -i conflicts.csv -g MIGRATION-GUID -
Если команда сообщит, что конфликты по-прежнему существуют, снова выполните процесс разрешения конфликтов миграции.
Применение импортированных данных к GitHub Enterprise Server
-
SSH в целевом экземпляре GitHub Enterprise Server. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).
ssh -p 122 admin@HOSTNAME -
С помощью команды запустите процесс импорта. Что вам понадобится:
- GUID миграции. Дополнительные сведения см. в статье "Подготовка перенесенных данных для импорта в GitHub Enterprise Server".
- Данные personal access token для проверки подлинности. Используемые данные personal access token используются только для проверки подлинности в качестве администратора сайта и не требуют каких-либо определенных областей или разрешений. Дополнительные сведения см. в разделе AUTOTITLE.
$ 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.
Проверка данных миграции
По умолчанию возвращает каждую запись. Кроме того, это позволяет фильтровать записи по следующим критериям:
- Типы записей.
- Состояние записей.
Типы записей соответствуют тем, которые находятся в перенесенных данных.
Фильтры типов записей
| Тип записи | Имя фильтра |
|---|---|
| Пользователи | 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 |
Фильтры состояния записи
| Состояние записи | Описание |
|---|---|
export | Запись будет экспортирована. |
import | Запись будет импортирована. |
map | Запись будет сопоставлена. |
rename | Запись будет сопоставлена. |
merge | Запись будет объединена. |
exported | Запись экспортирована успешно. |
imported | Запись импортирована успешно. |
mapped | Запись сопоставлена успешно. |
renamed | Запись переименована успешно. |
merged | Запись объединена успешно. |
failed_export | Не удалось экспортировать запись. |
failed_import | Не удалось импортировать запись. |
failed_map | Не удалось сопоставить запись. |
failed_rename | Не удалось переименовать запись. |
failed_merge | Не удалось объединить запись. |
Фильтрация записей аудита
С помощью команды можно отфильтровать данные по типу записи с помощью флага . Аналогичным образом можно отфильтровать состояние импорта с помощью флага . Эта команда выглядит следующим образом:
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 с помощью триггера , рабочие процессы не будут выполняться автоматически после импорта. Чтобы снова запустить запланированные рабочие процессы, отправьте фиксацию в репозиторий. Дополнительные сведения см. в разделе AUTOTITLE.
Разблокировка репозиториев в источнике
После завершения миграции необходимо разблокировать репозитории в источнике.
Разблокировка репозиториев из организации в GitHub.com
Чтобы разблокировать репозитории в организации GitHub.com, отправьте запрос в конечную точку разблокировки миграции. Что вам понадобится:
- Маркер доступа для проверки подлинности
- Уникальный миграции
- Имя репозитория для разблокировки
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