Как стать автором
Обновить

Комментарии 29

у них же Jenkins и Groovy. А git они знают плохо. Потому что они думают, что их конфиг соответствует тем командам git cli, и они думают, что
git clone <repo URL>
это shallow copy.

С другой стороны, в инструментах CI нужный refspec мог бы и по умолчанию добавляться. Особенно когда в других местах указано имя ветки и флаг shallow.

Я так как то раз ускорил клонирование классов-сервисов в ts в 500 раз, заменив lodash'ский deepClone на самописное творение без кеша. Хз что это было, но с каждым копированием, из-за наличия ссылок на самих себя, копирование замедлялось дико...

Любопытно, покажете ваше творение? :)
А я когда-то ускорял игры перепрограммируя таймер.

А я велел ускорял игры, нажимая кнопку Turbo на системнике… но у git почему-то нет такой кнопки ((

нет, это если CI происходит в worker-ах, которые можно менять, если у них есть состояние.

У нас, например, всё или в докер-образах или в VM-ах, которые строго read-only. Туда git pull не сделаешь. Правда мы обычно и git clone не делаем, но если было б надо — делали бы shallow copy, вытаскивая строго один нужный коммит.
У меня при depth=1 были какие-то проблемы, не помню, с чем именно (возможно, с submodules), но суть в том, что клонирование только последнего коммита работало коряво и приходилось брать больше (что тоже не было надёжным решением, просто мне хватало такой глубины, но надёжно — только всю историю).

По сути git clone --reference ... и решает все проблемы, которые присущи shallow clone, хоть и вносит новые (лучше всего в reference-репозитории хранить только master ветку, и никакую больше, чтобы был невозможен сценарий, когда после git gc или git prune пропали какие-то объекты из репозитория).

у нас никаких не было, и даже представить не могу, что там может быть. submodules надо клонировать отдельно, конечно, там depth=1 как-то странно работало

Команды вроде git log, git blame и других будут давать неправильные результаты :). Также мерж веток может быть невозможен, если общий предок был раньше, чем момент, где история заканчивается.

у нас CI собирает и тестирует, мержить им никто не позволяет :)

для blame/merge нужна, конечно, вся история.

Jenkins делает git log, что бы показать список коммитов, которые попали в текущий билд, но не попали в предыдущие.

Не уверен, что правильно понимаю. У вас r/о образы создаются сразу с нужным комплектом исходников?
Т.е. есть некая машина-фабрика, на которой вы держите репу, и никакого git clone на каждый чих не происходит, а просто извлекаете исходники посредством git update или git archive (в зависимости от того, куда их надо положить) + сборка образа?

по разному, у нас есть разные CI. Вот тут, например, есть один образ, который r/w и делает pull. Он собирает source tarball (да, git archive), остальные образы строго read-only собирают из этого тарбола. Образ собирается один раз, с компилятором и библиотеками. Тарбол заливается в образ по scp.

read-only решает сразу кучу проблем. Все тесты происходят в одном и том же окружении, никаких хвостов не остаётся. Если что повисло — можно прибить VM как угодно. Сборка проверяет, что всё хорошо собирается так же, как собирают пользователи — из того source tarball, что мы релизим. Можно одну и ту же VM запустить параллельно десяток раз.

Угу. Но в любом случае git clone выполняется крайне редко (примерно 1 раз – при настройке CI – в вашем случае создание r/w-образа). Так что непонятна эта битва за его оптимизацию в статье – shallow, refspec...

Ну мы-то и не оптимизируем. А они явно клонируют каждый раз. Поэтому им надо читать доки и делать shallow. Они почитали, сделали, и написали статью.

Вот я и не могу понять: зачем они клонируют? Какой в этом смысл? Почему им нужен репозиторий, а не исходники (снэпшот)?

Репозиторий нужен потому что без него снэпшот вы и не сделаете, это очевидно. А почему clone делается каждый раз — тут у меня две идеи.


Во-первых, некоторые инструменты CI не заморачиваются использованием имеющейся рабочей копии и делают clone каждый раз, если им в настройках указали флаг shallow. Возможно, Jenkins ведёт себя так же, точно не знаю.


Во-вторых, есть такая практика как очистка рабочей директории перед каждой сборкой (это когда вы не доверяете инкрементным билдам, либо точно знаете что они сломаны) — иногда эта фича включается просто галочкой, иногда нужно отдельный шаг писать. В любом случае папка .git тоже очищается.

Репозиторий нужен потому что без него снэпшот вы и не сделаете, это очевидно.

Второй экземпляр репозитория не нужен.
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".

средства-то умеют. Но те, кто читают документацию и правильно настраивают CI и VCS — они не пишут на medium каждый раз, когда осознают, как лопухнулись, делая checkout-ы всех веток вместо той одной, которую надо собирать.

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

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

20GB? Да что вы знаете о больших гит-репозиториях. В геймдеве репозитории меряют сотнями гигабайт. Рекордсмен, с которым я работал — 1.5ТБ. И это НЕ монорепозиторий, это ОДИН проект.

НЛО прилетело и опубликовало эту надпись здесь

Я честно и в 20GB текста не очень верю. Скорее всего неожиданно всякие картинки, dll/pdb/exe зависимостей, может docx/xlsx затесались. Но т.к. их мало, для них LFS никто не настраивал (вероятно).

Вот только они забыли в своей статье упомянуть, что нужно еще отключить дефолтный чекаут и включить опцию Honor refspec on initial clone, иначе ничего у вас не ускорится. Плюс 50 последних коммитов? Зачем? Для билда достаточно последнего
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории