Устранение неполадок миграции с помощью GitHub Enterprise Importer

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

В этой статье

Сведения об устранении неполадок для GitHub Enterprise Importer

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

Если вам не удается устранить проблему после попытки устранения неполадок сообщения об ошибке, вы можете связаться с Служба поддержки GitHub.

Первые шаги по устранению неполадок

Перед дальнейшим изучением попробуйте выполнить эти действия по устранению неполадок, которые обычно устраняют различные проблемы.

  1. Убедитесь, что вы используете последнюю версию расширения GitHub CLI для миграции. Если нет, обновите до последней версии.

  2. Убедитесь, что выполнены все требования к доступу. Дополнительные сведения см. в соответствующей статье для пути миграции.

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

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

Если эти действия не устраняют проблему, просмотрите журналы миграции для сообщений об ошибках. Журнал, который необходимо проверить, зависит от того, завершилась ли миграция сбоем или успешно выполнена.

Устранение неполадок с неудачными миграциями

Если миграция завершается ошибкой, просмотрите подробные записи журнала, созданные GitHub CLI для каждой миграции. Файл журнала сохраняется в том же каталоге, где выполняется миграция.

Журнал содержит запись каждой команды, которую вы вы выпустили, и все запросы API, которые GitHub CLI в ответе. Ошибки и сообщения об ошибках обычно отображаются в конце журнала.

Не удается выполнить миграцию

Если вы видите ошибку или No access to createMigrationMutation Missing permissions, личная учетная запись не имеет требуемого доступа для выполнения миграции. Убедитесь, что вы являетесь владелец организации или получили роль миграции. Дополнительные сведения о предоставлении роли миграции см. в разделе "Сведения о GitHub Enterprise Importer".

Note

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

Ресурс защищен принудительной защитой организации SAML

Эта ошибка означает, что для использования с единым входом SAML необходимо авторизовать . Дополнительные сведения см. в разделе Авторизация личного токена доступа для использования с документами единого входа SAML.

401 Unauthorized ответ

Сбои, 401 содержащие код состояния, обычно указывают на то, что у personal access token , предоставленных GitHub CLI нет необходимых областей. Проверьте области в предоставленных вами областях данных personal access token. Дополнительные сведения о необходимых областях см. в соответствующей статье для пути миграции.

404 Not Found ответ

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

Archive generation failed ответ

Если при миграции из GitHub Enterprise Server, Archive generation failed... репозиторий, вероятно, слишком велик. Дополнительные сведения о ограничениях размера репозитория см. в разделе "Сведения о миграции между продуктами GitHub".

Сначала попробуйте исключить выпуски из миграции с помощью флага --skip-releases migrate-repo с помощью команды.

Если это не работает, рекомендуется обновить до GitHub Enterprise Server 3.8.0 или более поздней версии. Если вам не удается обновить, другой вариант — создать архивы репозитория вручную с помощью ghe-migrator:

  1. Создайте архив миграции для репозитория. Необходимо экспортировать только один репозиторий одновременно. Инструкции см. в разделе "Экспорт данных миграции из вашей организации" в документации GitHub Enterprise Server.
  2. Отправьте архив миграции в выбранный поставщик хранилища BLOB-объектов.
  3. Создайте короткий URL-адрес архива миграции, который доступен для GitHub, например ПРЕДВАРИТЕЛЬНО подписанный URL-адрес AWS S3 или URL-адрес SAS Хранилище BLOB-объектов Azure.
  4. migrate-repo Вызовите команду с --git-archive-url флагами и --metadata-archive-url задайте URL-адрес архива из предыдущего шага.

Ошибок: cipher name is not supported

Если вы выполняете миграцию с Bitbucket Server и получаете ошибку, например cipher name aes256-ctr for openssh key file is not supported при выполнении миграции, закрытый ключ SSH использует неподдерживаемый шифр. Дополнительные сведения о поддерживаемых шифрах см. в разделе "Управление доступом к миграции с сервера Bitbucket".

Чтобы создать новый совместимый ключ SSH, выполните следующую команду:

Shell
ssh-keygen -t ed25519 -Z aes256-cbc -C "your_email@example.com"

После создания нового ключа SSH перед использованием ключа необходимо добавить открытый ключ в экземпляр authorized_keysBitbucket Server.

Ошибок: Subsystem 'sftp' could not be executed

Если вы выполняете миграцию с Bitbucket Server и получаете ошибку, например Subsystem 'sftp' could not be executedSFTP, не включена на сервере или у вашей учетной записи пользователя нет доступа SFTP.

Обратитесь к администратору сервера и попросите его включить доступ SFTP к учетной записи пользователя.

Ошибок: Source export archive... does not exist

Если вы выполняете миграцию с Bitbucket Server и получаете сообщение об ошибке, например Source export archive (/var/atlassian/application-data/bitbucket/shared/migration/export/Bitbucket_export_1.tar) does not existGitHub CLI ищет архив миграции в неправильном месте на экземпляре Сервера Bitbucket.

Чтобы устранить эту проблему, задайте --bbs-shared-home аргумент для gh bbs2gh migrate-repo сервера Bitbucket или общего домашнего каталога Центра обработки данных. Общий домашний каталог по умолчанию, /var/atlassian/application-data/bitbucket/sharedно конфигурация может отличаться.

Вы можете определить общий домашний каталог в Bitbucket Server.

  1. Перейдите в область администрирования экземпляра Bitbucket Server или Data Center.
  2. На боковой панели в разделе "Система" щелкните "Хранилище".
  3. В разделе "Общий каталог" просмотрите расположение общего домашнего каталога сервера.

Если вы используете Bitbucket Data Center в режиме кластера с несколькими заметками, общий каталог будет совместно использоваться между узлами кластера и должен быть подключен в одном расположении на каждом узле.

Ошибок: Repository rule violations found

При возникновении Repository rule violations found ошибки, например GH013: Repository rule violations found for refs/heads/main, данные в репозитории источников конфликтуют с наборами правил, настроенными в целевой организации. Дополнительные сведения см. в разделе Сведения о наборе правил.

Вы можете временно отключить наборы правил во время миграции или использовать режим обхода или список обходов, чтобы исключить миграцию из настроенных правил. Дополнительные сведения см. в разделе Управление наборами правил для репозиториев в организации.

Ошибок: Your push would publish a private email address

Если вы получаете Git source migration failed сообщение об ошибке GH007: Your push would publish a private email address, источник Git, который вы пытаетесь перенести, включает фиксации, созданные адресом электронной почты, который вы заблокировали от отправки в GitHub. Дополнительные сведения см. в разделе "Блокировка отправок из командной строки, которые раскрывают ваши личные адреса электронной почты".

Чтобы устранить эту ошибку, можно переписать журнал Git, чтобы удалить адрес электронной почты, или отключить параметр "Блокировать отправки командной строки, предоставляющие мою электронную почту".

Общие сведения о предупреждениях журнала миграции

Даже если миграция выполнена успешно, необходимо проверить журнал миграции, чтобы проверить наличие предупреждений.

Предупреждения в журнале миграции указывают на определенные элементы в репозитории, которые не удалось перенести. Дополнительные сведения см. в разделе Доступ к журналам миграции для GitHub Enterprise Importer.

Note

Если проблема "Журнал миграции" включает "Миграция завершена" в нижней части, репозиторий был перенесен. Предупреждения указывают только на то, что определенные элементы в репозитории, например комментарий к запросу на вытягивание, могут не переноситься правильно.

Предупреждение: "Метаданные репозитория слишком большие для миграции"

Если в проблеме "Журнал миграции" отображается сообщение "Слишком большие метаданные репозитория" или GitHub CLI, репозиторий превышает максимальный размер архива в 10 ГБ. Это часто вызвано большими ресурсами выпуска. Попробуйте исключить выпуски из миграции с флагом --skip-releases для migrate-repo команды.

Предупреждение: "Комментарий не в диффе"

Если вы выполняете миграцию из Azure DevOps, комментарии запроса на вытягивание в строках, которые никогда не были изменены в запросе на вытягивание, нельзя перенести на GitHub. Вы увидите это предупреждение для каждого комментария, который не может быть перенесен по этой причине.

Note

Это ограничение влияет только на комментарии к строкам, которые не были изменены в запросе на вытягивание. Комментарии по строкам, которые были изменены в запросе на вытягивание, переносятся.

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

Предупреждение: "Проверка запроса на вытягивание... не удалось импортировать из-за ошибки REVIEW_THREAD_MISSING_END_COMMIT_OID"

Это предупреждение возникает, когда не удалось перенести проверка запроса на вытягивание, так как фиксация, к которой присоединена проверка, больше не существует.

Обычно это происходит, когда фиксации были удалены с помощью принудительная отправка, или ветвь была удалена.

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

Ссылки группы прерваны после миграции организации

Ссылки на команды, например@octo-org/octo-team, не** обновляются **в рамках миграции организации. Это может вызвать проблемы в целевой организации, например CODEOWNERS файлы, которые не работают должным образом.

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

Например, если ваша исходная организация имеет @octo-org``CODEOWNERS ссылку на команду@octo-org/octo-team, вы можете переименовать исходную организацию @octo-org-temp до миграции, что позволяет использовать @octo-org в качестве имени новой организации. Затем будет вызвана @octo-org/octo-teamперенесенная команда, и CODEOWNERS файл в перенесенном репозитории будет работать должным образом.

Заблокированные репозитории

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

Процесс разблокировки репозитория зависит от продукта GitHub, в котором хранится репозиторий.

  • Если заблокированный репозиторий находится на GitHub Enterprise Server, администратор сайта может разблокировать репозиторий с помощью панели мониторинга администратора сайта. Дополнительные сведения см. в разделе "Блокировка репозитория" в документации GitHub Enterprise Server.
  • Если заблокированный репозиторий находится на GitHub.com, можно связаться с для разблокировки репозитория.

Note

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

Обращение к Служба поддержки GitHub

Если вам по-прежнему не удается устранить проблему после выполнения описанных выше действий по устранению неполадок, можно связаться с Служба поддержки GitHub с помощью Портал поддержки GitHub.