Подробно о работе ГД при подготовке репозитория гитлаб

dr_korolevdr_korolev
Раздел: Прочие темы

Кто-нибудь знает подробно как именно работает приложение ГД, когда используется гитлаб для формирования обновлений? Допустим удаленный реп используется долгое время, накопилось огромное кол-во файлов в разных ветках, размер репы > 2 GB. После рестарта контейнера с приложением, заходим в раздел установки обновлений и ждем подготовку репозитория, процесс может занимать до 30-40 минут. Что именно в этот момент делает приложение? Просто клонирует реп и парсит файлы из соответсвующей стенду ветки? Кто нибудб пробовал чистить реп? Что больше влияет на подготовку репозитория в приложении, кол-во файлов или размер репозитория?

Вообще были ли у кого-нибудь успешные кейсы очистки репозитория

Комментарии

  • Сергеев Илья GDСергеев Илья GD

    Добрый день. Подготовим рекомендации

  • zonov_avzonov_av

    Какая версия приложения используется вами?

  • zonov_avzonov_av

    Подготовили ответы на ваши вопросы
    1. как именно работает приложение ГД, когда используется гитлаб для формирования обновлений?
    При запуске приложение клонирует 4 репозитория:

    • DEV - там лежат все обновления - клонируется ветка dev и дочерние ветки
    • TEST - список обновлений, отправленных на тест - клонируется ветка test
    • RELEASE - список поставок и релизов - клонируется ветка release
    • ROLLBACK - данные об установке на текущий стенд и данные для отката - клонируется ветка rollback
      В дальнейшем, приложение работает с этими локальными репозиториями, также обновляет ветки из удаленного репозитория и пушит в удаленный репозиторий.

    1. Что именно в этот момент делает приложение?
      При старте приложение клонирует репозитории только с нужными ветками.

    2. Что больше влияет на подготовку репозитория в приложении, кол-во файлов или размер репозитория?
      На подготовку репозитория влияет занимаемый им размер.

    3. Были ли успешные кейсы очистки репозитория?
      Да, у нас имеется такой кейс.

    Рекомеданций для очистки репозитория
    Почистить частично - технически не возможно, поскольку каждое обновление - это коммит и если схлопнуть часть коммитов, то у остальных поменяется SHA и испортятся ссылки на эти обновления в ветках test, release **и **rollback
    Примерный алгоритм очистки:

    1. создать новые, пустые ветки dev-2026, test-2026, release-2026, rollback-2026 (для каждого стенда своя)
    2. все обновления, которые были сформированы, отправить на тест
    3. переключить стенд dev на новые ветки
    4. все обновления, которые были отправлены на тест - установить на test
    5. сформировать с этими обновлениями поставки и релизы
    6. переключить стенд test на новые ветки
    7. после установки всех обновлений на релизные стенды можно эти стенды переключать на новые ветки

    Переключение стенда между старыми и новыми ветками:
    меняем в настройках все ветки
    запускаем /api/sys/update/git/clone-repository

  • dr_korolevdr_korolev

    @zonov_av написал:
    Какая версия приложения используется вами?

    У нас отдельная версия в компании. По сути как описано в вике так и работает
    https://docs.greendata.ru/platform/ru/update-system.html#podkluchenie

  • dr_korolevdr_korolev

    @zonov_av написал:
    Подготовили ответы на ваши вопросы
    1. как именно работает приложение ГД, когда используется гитлаб для формирования обновлений?
    При запуске приложение клонирует 4 репозитория:

    • DEV - там лежат все обновления - клонируется ветка dev и дочерние ветки
    • TEST - список обновлений, отправленных на тест - клонируется ветка test
    • RELEASE - список поставок и релизов - клонируется ветка release
    • ROLLBACK - данные об установке на текущий стенд и данные для отката - клонируется ветка rollback
      В дальнейшем, приложение работает с этими локальными репозиториями, также обновляет ветки из удаленного репозитория и пушит в удаленный репозиторий.

    1. Что именно в этот момент делает приложение?
      При старте приложение клонирует репозитории только с нужными ветками.

    2. Что больше влияет на подготовку репозитория в приложении, кол-во файлов или размер репозитория?
      На подготовку репозитория влияет занимаемый им размер.

    3. Были ли успешные кейсы очистки репозитория?
      Да, у нас имеется такой кейс.

    Рекомеданций для очистки репозитория
    Почистить частично - технически не возможно, поскольку каждое обновление - это коммит и если схлопнуть часть коммитов, то у остальных поменяется SHA и испортятся ссылки на эти обновления в ветках test, release **и **rollback
    Примерный алгоритм очистки:

    1. создать новые, пустые ветки dev-2026, test-2026, release-2026, rollback-2026 (для каждого стенда своя)
    2. все обновления, которые были сформированы, отправить на тест
    3. переключить стенд dev на новые ветки
    4. все обновления, которые были отправлены на тест - установить на test
    5. сформировать с этими обновлениями поставки и релизы
    6. переключить стенд test на новые ветки
    7. после установки всех обновлений на релизные стенды можно эти стенды переключать на новые ветки

    Переключение стенда между старыми и новыми ветками:
    меняем в настройках все ветки
    запускаем /api/sys/update/git/clone-repository

    Спасибо, попробую

Войдите или Зарегистрируйтесь чтобы комментировать.

© Vanilla Keystone Theme 2025