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

О шагах по устранению неполадок GitHub Enterprise Importer

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

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

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

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

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

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

   •      [AUTOTITLE](/migrations/using-github-enterprise-importer/migrating-from-bitbucket-server-to-github-enterprise-cloud/managing-access-for-a-migration-from-bitbucket-server)
     

   •      [AUTOTITLE](/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products)
     

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

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

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

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

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

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

• Не удается выполнить миграцию
• Ресурс защищен принудительной защитой организации SAML
• 401 Unauthorized ответ
• 404 Not Found ответ
• Archive generation failed ответ
• Ошибка cipher name is not supported
• Ошибка Subsystem 'sftp' could not be executed
• Ошибка Source export archive... does not exist
• Ошибка Repository rule violations found
• Ошибка Your push would publish a private email address

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

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

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

Эта ошибка указывает на то, personal access token что вам GitHub CLI нужно авторизовать использование с SAML single sign-on. Дополнительные сведения см. в разделе Авторизация личного маркера доступа для использования с единым входом.

          `401 Unauthorized` ответ

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

•      [AUTOTITLE](/migrations/using-github-enterprise-importer/migrating-from-bitbucket-server-to-github-enterprise-cloud/managing-access-for-a-migration-from-bitbucket-server#required-scopes-for-personal-access-tokens)
  

•      [AUTOTITLE](/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#required-scopes-for-personal-access-tokens)
  

          `404 Not Found` ответ

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

          `Archive generation failed` ответ

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

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

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

1. Создайте архив миграции для репозитория. Необходимо экспортировать только один репозиторий одновременно. Для инструкций см. раздел «Экспорт данных миграции из вашего предприятия».
2. Отправьте архив миграции в выбранный поставщик хранилища BLOB-объектов.
3. Сгенерируйте кратковременный URL для вашего архива миграции, доступный для GitHub, например, заранее подписанный URL AWS S3 или Хранилище BLOB-объектов Azure SAS.

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, выполните следующую команду:

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

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 exist, он GitHub CLI ищет ваш архив миграции не в том месте на вашем экземпляре Bitbucket Server.

Чтобы устранить эту проблему, задайте --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. Для получения дополнительной информации см. Блокировка отправок из командной строки, которые раскрывают ваши личные адреса электронной почты в GitHub Enterprise Cloud документации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обзор pull request импортируется в виде встроенного комментария к pull request-запросу

Эти предупреждения указывают на то, что проверку pull request нельзя было перенести в оригинальном виде, а в комментариях к встроенным pull request-запросам:

• INVALID_REVIEW_THREAD
• LINE_NOT_FOUND_IN_DIFF
• REVIEW_THREAD_MISSING_BODY

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

Ссылки на команды, например@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.com, вы можете связаться ваш администратор сайта с ним, чтобы открыть репозиторий.

Связь Служба поддержки GitHub

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