Недостатки мелкого клонирования на Travis и других сервисах CI?

Question

Большинство служб CI предоставляют способ неглубокого клонирования хранилища. Например, на Travis:

git: 
    depth: 1 

или AppVeyor:

clone_depth: 1 
or 
shallow_clone: true 

Это имеет очевидное преимущество в скорости, так как вы не должны клонировать весь репозиторий.

Есть ли недостатки для мелкого клонирования служб CI? Есть ли какая-то ситуация, когда мелкий клоун сделает сборку CI неудачной? В противном случае, почему не является мелким клонированием значения по умолчанию для этих служб CI?

Answer 1

Есть две причины, почему это обычно не происходит.

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

Во-вторых, большинство серверов Git имеют возможность отправлять оптимизированный «all.pack», если у вас нет подробностей. В противном случае серверу необходимо будет предоставить специальный пакет фиксации, содержащий только вашу мелкую копию для отправки вам. Поэтому, хотя может быть больше данных, передаваемых по кабелю, это может привести к большей работе на сервере.

Наконец, довольно много CI-сборок выполнит какую-то операцию тегов и загрузит их в репозиторий, и вы не сможете практически пометить мелкий клон (см. Пункт 1).

Answer 2

Добавление ответа AlBlue в:

Другая проблема заключается в том, что установка глубины клон также используется для мерзавца субмодуля.

В проектах, которые используют подмодуль git, Travis и т. Д. Будут клонировать репозиторий подмодулей, начиная с мастера, а затем проверить конкретную ревизию.

Если фиксация, на которую мы указываем в подмодуле, находится не внутри n коммитов текущего мастера (где n - значение глубины), тогда он не сможет проверить.