Комментарии 29
Что же будет, когда они узнают про опцию --reference...
git clone <repo URL>
это shallow copy.
Я так как то раз ускорил клонирование классов-сервисов в ts в 500 раз, заменив lodash'ский deepClone на самописное творение без кеша. Хз что это было, но с каждым копированием, из-за наличия ссылок на самих себя, копирование замедлялось дико...
Не понял. Для CI нужно же git archive, нет?
Ну или (лучше) один раз сделан git clone при развёртывании CI, а дальше git pull (+ git update / git archive).
У нас, например, всё или в докер-образах или в VM-ах, которые строго read-only. Туда git pull не сделаешь. Правда мы обычно и git clone не делаем, но если было б надо — делали бы shallow copy, вытаскивая строго один нужный коммит.
По сути git clone --reference ...
и решает все проблемы, которые присущи shallow clone, хоть и вносит новые (лучше всего в reference-репозитории хранить только master ветку, и никакую больше, чтобы был невозможен сценарий, когда после git gc или git prune пропали какие-то объекты из репозитория).
Команды вроде git log
, git blame
и других будут давать неправильные результаты :). Также мерж веток может быть невозможен, если общий предок был раньше, чем момент, где история заканчивается.
Не уверен, что правильно понимаю. У вас r/о образы создаются сразу с нужным комплектом исходников?
Т.е. есть некая машина-фабрика, на которой вы держите репу, и никакого git clone на каждый чих не происходит, а просто извлекаете исходники посредством git update или git archive (в зависимости от того, куда их надо положить) + сборка образа?
read-only решает сразу кучу проблем. Все тесты происходят в одном и том же окружении, никаких хвостов не остаётся. Если что повисло — можно прибить VM как угодно. Сборка проверяет, что всё хорошо собирается так же, как собирают пользователи — из того source tarball, что мы релизим. Можно одну и ту же VM запустить параллельно десяток раз.
Угу. Но в любом случае git clone выполняется крайне редко (примерно 1 раз – при настройке CI – в вашем случае создание r/w-образа). Так что непонятна эта битва за его оптимизацию в статье – shallow, refspec...
Ну мы-то и не оптимизируем. А они явно клонируют каждый раз. Поэтому им надо читать доки и делать shallow. Они почитали, сделали, и написали статью.
Вот я и не могу понять: зачем они клонируют? Какой в этом смысл? Почему им нужен репозиторий, а не исходники (снэпшот)?
Репозиторий нужен потому что без него снэпшот вы и не сделаете, это очевидно. А почему clone делается каждый раз — тут у меня две идеи.
Во-первых, некоторые инструменты CI не заморачиваются использованием имеющейся рабочей копии и делают clone каждый раз, если им в настройках указали флаг shallow. Возможно, Jenkins ведёт себя так же, точно не знаю.
Во-вторых, есть такая практика как очистка рабочей директории перед каждой сборкой (это когда вы не доверяете инкрементным билдам, либо точно знаете что они сломаны) — иногда эта фича включается просто галочкой, иногда нужно отдельный шаг писать. В любом случае папка .git тоже очищается.
Взглюкнуло что-то (возможно, при нажатии "предпросмотр" ответ отсоединился от треда), ответ ниже – https://habr.com/ru/post/527116/#comment_22283168
Репозиторий нужен потому что без него снэпшот вы и не сделаете, это очевидно.
Второй экземпляр репозитория не нужен.
git archive master | tar -x -C /somewhere/else
(ну или git archive --remote ..., если надо втянуть из внешнего репозитория)
А почему clone делается каждый раз — тут у меня две идеи.
Неубедительно :-).
На билд-машине, понятное дело, спокойней делать билд с нуля, но убирать для этого папку .git ни к чему – это раз. Находиться она может вне доступа билд-скрипта (git worktree add) – это два. И я довольно-таки уверен, что мало-мальски продвинутые средства для CI умеют в git archive (а в самописные можно добавить) – это три. Google "jenkins git archive" или "jenkins pipeline git archive".
А те кто пишут — для них каждый взгляд в документацию — открытие. В итоге имеем то, что имеем.
Всё это монорепозитории с большим наборов сервисов, специфичных для языка.
Дочитал до сюда, мой мозг сломался. Народ требует адекватных переводов иностранных текстов. Пришлось читать в оригинале
20GB? Да что вы знаете о больших гит-репозиториях. В геймдеве репозитории меряют сотнями гигабайт. Рекордсмен, с которым я работал — 1.5ТБ. И это НЕ монорепозиторий, это ОДИН проект.
Одна строка, которая ускорила клонирование в 100 раз