Вопрос. Имеем большие репозитории и медленные скорости. Из-за чего очень

долго длятся пайплайны.
Azure DevOps, PR пайплан, выкачиваем только эфимерный(виртуальный) комит, и запускаем на нем werf build --repi xxx ($WERF_VIRTUAL_MERGE стоит в true). Запускается фетчинг и выполняется 3 раза по 3-4 минуты, потому что в werf.yaml на стапеле у нас описаны 3 образа в которых есть git maping. Делаем сборку, после чего запускаются(если надо) около 15 джоб которые на этом же виртуальном комите делают werf plan.

Все работает, но очень медленно. Начали играться-ковырятся. Сделали
forceShallowClone: true
allowUnshallow: false

Werf перестала делать фетч и сборка стала адекватной по скорости. Но следующие джобы, которые на том же комите со всеми теми же настройками запускаются пытаются пересобирать образа... Как будто бы не видят кэш в репо.
Добавил флаг $WERF_REQUIRE_BUILT_IMAGES, и мне сообщает мол такой-то номер образа не найден, а в репо он есть, и на предыдущем шаге в логах видно что он собрался и лег в кэш

Вопрос зачем мы делаем фетч 3 раза для репозитория который есть локально? Притом 3 раза отдельно и последовательно. И как быть с пкресборками на одном комите с настройками
forceShallowClone: true
allowUnshallow: false

Версия 2.7.1

Зачем вы используете WERF_VIRTUAL_MERGE?

Основной fetch вызывается для того, чтобы выполнить unshallow и подтянуть историю коммитов. Что касается 3 раз, то хорошо бы посмотреть дебаг лог WERF_DEBUG_TRUE_GIT=1 WERF_DEBUG=1.

Через дебаг я понял что фетч запускается для каждого образа где я делаю гитмапинг

Git mapping с remote используется или только local?

Только локал, одна репа, 3 разных директории на которые натравливаюсь

А там точно fetch происходит? С таким текстом "Fetching origin"? Какая у вас версия Git?

┌ Fetching origin └ Fetching origin (198.27 seconds) ┌ Fetching origin └ Fetching origin (198.66 seconds) ┌ Fetching origin └ Fetching origin (196.09 seconds) git version 2.25.1

Сегодня не успели. Завтра доберёмся

ну по факту мы порешали сейчас так, что качаем теперь всю репу со всей историей на системном чекауте от Azure Devops, и ставим forceShallowClone: true allowUnshallow: false и нету этих перекачиваний, и кеш работает как хотели. Немного долго качается на системном, но лучше чем 3 раза на самом билде

Если вся история, то werf и не будет fetch выполнять. Только в случае shallow.

завтра перепроверю. такое ощущение что перекачивало...но перепроверю