Большинство служб CI предоставляют путь к мелкому клонированию репозитория. Например, на Travis:
git:
depth: 1
или на AppVeyor:
clone_depth: 1
or
shallow_clone: true
Это имеет очевидное преимущество скорости, поскольку вам не нужно клонировать весь репозиторий.
Есть ли недостатки для мелкого клонирования служб CI? Есть ли какая-то ситуация, когда мелкий клоун сделает сборку CI неудачной? В противном случае, почему не является мелким клонированием значения по умолчанию для этих служб CI?
Есть две причины, почему это обычно не происходит.
Во-первых, хэш неглубокого клона будет отличаться от любой версии, которую вы можете иметь в репозитории. В результате не удастся отслеживать сборку, которую вы сделали с каким-либо конкретным результатом.
Во-вторых, большинство серверов Git имеют возможность отправлять оптимизированный "all.pack", если у вас нет подробностей. В противном случае серверу необходимо будет предоставить специальный пакет фиксации, содержащий только вашу мелкую копию для отправки вам. Поэтому, хотя может быть больше данных, передаваемых по кабелю, это может привести к большей работе на сервере.
Наконец, довольно много CI-сборок выполнит какую-то операцию тега и загрузит его в репозиторий, и вы не сможете практически пометить неглубокий клон (см. пункт 1).
Добавление в ответ AlBlue:
Другая проблема заключается в том, что настройка глубины клона также используется для подмодуля git.
В проектах, которые используют подмодуль git, Travis и т.д., клонируют репозиторий подмодулей, начиная с мастера, а затем проверяют конкретную ревизию.
Если фиксация, на которую мы указываем в подмодуле, не находится в пределах n коммитов текущего мастера (где n - значение глубины), тогда он не сможет проверить.
В Travis CI по умолчанию используется клон глубиной 50.
Документация TravisCI, git-clone-глубина:
git: depth: 3 # Or remove the --depth flag entirely with: git: depth: false
В AppVeyor по умолчанию клонируется весь репозиторий.
AppVeyor предлагает как настройку глубины клонирования, так и альтернативную shallow_clone: true, где фиксация загружается в виде zip-архива с использованием GitHub или Bitbucket API. (Документация AppVeyor.)
Описание в справочнике appveyor.yml:
# fetch repository as zip archive shallow_clone: true # default is "false" # set clone depth clone_depth: 5 # clone entire repository history if not defined
Использование (clone_)depth: 1 часто приводит к ошибке git, когда новый коммит (clone_)depth: 1 в ветку до того, как платформа CI начала клонировать предполагаемый коммит. Как в AppVeyor, так и в TravisCI, с обычными операциями отправки в репозиторий на GitHub.
Пример вывода неудачной проверки на AppVeyor:
Build started
git clone -q --depth=1 --branch=<branch_name> https://github.com/<user>/<repo_name>.git C:\projects\<repo_name>
git checkout -qf 53f3f9d4d29985cc6e56764c07928a25d94477ed
fatal: reference is not a tree: 53f3f9d4d29985cc6e56764c07928a25d94477ed
Command exited with code 128
Обратите внимание, что никакой конкретный коммит не был получен!
Использование альтернативы shallow_clone: true:
Build started
Fetching repository commit (6ad0f01)...OK
Total: 781.1 KB in 76 files
Я не видел проблем с проектами, использующими shallow_clone: true.
Вторичный результат при использовании ограниченной глубины состоит в том, что перезапуск сборок CI на старых коммитах завершится неудачей, когда выйдет за пределы этого диапазона.
На AppVeyor я бы посоветовал использовать shallow_clone: true если репозиторий доступен на GitHub или Bitbucket. Если вы не хотите делать git-операции над кодом, это кажется лучшим вариантом.
На TravisCI не установка глубины (и использование глубины по умолчанию 50) кажется разумной. Вы можете использовать другое значение, если вы не хотите запускать исторические сборки или оптимизировать в зависимости от трафика в хранилище.
На внешние зависимости обычно ссылаются по ветке или тегу. При получении клона ветки или тега не должно быть проблем с использованием флага git --depth=1.