Миграция GitLab через gh gl2gh: dry-run и границы GitHub Enterprise Importer. Снять inventory проектов, размеров, lfs, visibility, участников и интеграций, проверить destination и выполнить пробную миграцию одного некритичного проекта; результат оформить как manifest миграции «source project id → destination org/repo → refs/counts → users mapping →…
Исходная граница: GitLab importer
Сформулируйте результат как проверяемую границу, а не как универсальный диагноз. Наблюдаемая боль: Команда планирует миграцию GitLab и может перепутать поддерживаемое назначение GitHub Enterprise Cloud с GHES, не проверить mapping пользователей или начать production-import без инвентаря. До любых действий запишите дату, точную роль, тип объекта, edition или клиент, исходное значение и ожидаемый результат. Рабочая задача этого разбора: снять inventory проектов, размеров, LFS, visibility, участников и интеграций, проверить destination и выполнить пробную миграцию одного некритичного проекта. Не меняйте одновременно policy, версию клиента и содержимое проверяемого объекта: иначе результат нельзя будет связать с одной переменной. Публичная запись должна содержать только обезличенные статусы; имена, приватные адреса, токены, полный журнал и рабочее содержимое исключаются.
Доказательная база для GitLab importer
Первичный источник подтверждает следующее: GitHub объявил GitLab migration через GitHub Enterprise Importer и CLI extension gh gl2gh; объявление относится к поддерживаемым назначениям GitHub Enterprise Cloud, а не к GitHub Enterprise Server. Второй официальный источник уточняет: Документация миграции из GitLab описывает prerequisites, access tokens, migration и post-migration steps; секреты должны передаваться только защищённо. Дата публикации не заменяет диагностику. Сверяйте feature boundary, роль, edition и фактический результат в тестовом окружении. Поэтому ожидаемый артефакт — manifest миграции «source project id → destination org/repo → refs/counts → users mapping → issues/MR counts → exclusions → rollback owner». Он фиксирует проверяемые поля и не утверждает, что функция популярна, что она уже доступна каждому аккаунту или что именно релиз вызвал любой похожий симптом. Дату и технические свойства следует брать с прямых страниц, а не из заголовка агрегатора.
Обратимый опыт: GitLab importer
Контрольный тест сформулирован так: Импортировать учебный проект в временную организацию, сверить commit graph, default branch, issues и merge requests, затем удалить тестовое назначение по согласованной процедуре. Перед началом сохраните исходное значение, идентификатор тестового объекта и способ возврата. Выполните одно действие, дождитесь одного измеримого ответа и внесите его в manifest миграции «source project id → destination org/repo → refs/counts → users mapping → issues/MR counts → exclusions → rollback owner». Положительный результат подтверждает только эту ветку в данном окружении; отрицательный исключает только проверенное условие. Повтор допустим на той же версии и с теми же входными данными, без серии очисток, переустановок и расширения прав.
Матрица решений по GitLab importer
Сначала сравните expected и actual для контрольного объекта. Если они совпали, выполните возврат и подтвердите, что исходное состояние восстановлено. Если не совпали, проверьте effective role, policy, scope и version, затем переходите только к одной соседней ветке. Основной инструмент — manifest миграции «source project id → destination org/repo → refs/counts → users mapping → issues/MR counts → exclusions → rollback owner». Отдельная строка нужна для неизвестного состояния: она честнее преждевременного диагноза. Совпадение даты или названия не доказывает регрессию; доказательством служит воспроизводимый before/after с одной изменённой переменной и границей из официальной документации.
Стоп-линия и эскалация: GitLab importer
Критерий остановки: Не начинать production-import при неверном destination, неполном user mapping, неизвестном объёме LFS, незащищённых токенах или отсутствии backup source. Для эскалации подготовьте минимальный пакет: UTC-время, версию клиента или API, тип аккаунта, обезличенный идентификатор объекта, expected и actual, один контрольный шаг, результат возврата и ссылки на два официальных источника. Скриншот обрежьте до нужной области. Не прикладывайте приватные URL, email, секреты, конфигурацию организации целиком, database, HAR или необработанный лог. Такой пакет позволяет проверить именно «GitLab importer» без опасных необратимых изменений.
Материал подготовлен редакцией VOne с помощью ИИ; все технические утверждения постатейно сверены с указанными официальными источниками 28 августа 2026 года.
Источники и проверка
- Официальный GitHub Changelog проверено 2026-08-28
- Официальная техническая документация проверено 2026-08-28
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.