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

Инструкции по устранению неполадок для GitHub Enterprise Importer

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

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

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

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

1. Убедитесь, что вы используете последнюю версию расширения GitHub CLI, используемого для миграции. В противном случае обновите до последней версии.
2. Убедитесь, что выполнены все требования к доступу. Дополнительные сведения см. в разделе Управление доступом для GitHub Enterprise Importer.
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, личная учетная запись не имеет доступа, необходимого для выполнения миграции. Убедитесь, что вы являетесь владелец организации или ему назначена роль миграции. Дополнительные сведения о предоставлении роли миграции см. в разделе Migrating repositories with GitHub Enterprise Importer.

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

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

401 Unauthorized Ответ

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

404 Not Found Ответ

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

Archive generation failed Ответ

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

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

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

1. Создайте архив миграции для репозитория. Необходимо экспортировать только один репозиторий за раз. Инструкции см. в разделе Экспорт данных миграции из предприятия.
2. Отправьте архив миграции выбранному поставщику хранилища BLOB-объектов.
3. Создайте кратковременный URL-адрес для архива миграции, который доступен для GitHub.com, например предварительно подписанный 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 использует неподдерживаемый шифр. Дополнительные сведения о поддерживаемых шифрах см. в разделе Управление доступом для GitHub Enterprise Importer.

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

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 executed, SFTP не включена на сервере или ваша учетная запись пользователя не имеет доступа по протоколу 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 или экземпляра центра обработки данных.
2. На боковой панели в разделе "Система" щелкните "Хранилище".
3. В разделе "Общий каталог" просмотрите расположение общего домашнего каталога сервера.

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

Ошибок: 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.

• Слишком большие метаданные репозитория для миграции
• Комментарий не в diff
• Поток проверки запроса на вытягивание не перенесен в запрос на вытягивание
• Ссылки команды не работают после миграции организации

Слишком большие метаданные репозитория для миграции

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

Комментарий не в diff

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

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

Поток проверки запроса на вытягивание не перенесен в запрос на вытягивание

Это предупреждение является более универсальной формой "Комментарий не в diff". Если вы видите это предупреждение, комментарий к файлу в запросе на вытягивание не может быть перенесен по причине, отличной от описанной выше. Чаще всего комментарий был указан в строке, которая была изменена в какой-то момент в журнале запросов на вытягивание, но затем запрос на вытягивание изменился, и это больше не так.

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

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

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

Ссылки команды не работают после миграции организации

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

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

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

Обращение к Поддержка GitHub

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