Как я могу получить несколько сборников Jenkins для работы из одного локального репозитория git?

У меня есть репозиторий GitHub, который большой и содержит несколько независимых битов. Если я сконфигурировал Дженкинса с заданием (или двумя) для каждого из них, я получаю многократное извлечение гигабайт данных (один клон репо для каждого задания).

Это занимает как дисковое пространство, так и пропускную способность.

Мне бы хотелось, чтобы у меня было задание "Обновить локальное репо", которое клонирует github один раз, затем настраивает каждое из заданий, чтобы клонировать себя из этого репо и строить. Затем, создав подзаголовки как зависимые сборки, я могу запустить "Обновить локальное репо", заставить его вытащить все последние данные из GitHub, а затем запустить каждую из них.

До сих пор у меня работало "Refresh local repo" - он успешно клонирует, и если я перехожу к рабочему пространству, я вижу, что он имеет HEAD-фиксацию origin/master.

Проблема заключается в других заданиях - они, похоже, не собирают обновления. Вот как я настроил один из них:

Git
 Repository URL file:////Users/malcolmbox/.jenkins/jobs/Refresh Local repo/workspace
 Branches to build  master

Вместо этого обновления до последней фиксации он застрял несколько дней назад.

Как я могу заставить его потянуть наконечник и сделать правильную вещь?

Чтобы уточнить:.../Обновить Локальное репо/рабочее пространство имеет фиксацию 6b20268389064590147d5c73d2b6aceb6ba5fe70 отправлено 28/3

Зависимая сборка после запуска сборки (так что, предположительно, выполняющая шаг клон/тяга git), выставляется на 79a25992cc192376522bcb634ee0f7eb3033fc7e, представленная 26/3, - так что это на пару дней позади.

Ответ 1

Если вы откроете конфигурацию задания и нажмите кнопку "Дополнительно" в конфигурации git SCM, вы увидите место, где следует указать "Путь ссылочного репо для использования во время клонирования (необязательно)".

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

Git затем будет использовать локальный клон и поделиться большинством объектов git на диске и вытащить из github только то, чего не хватает в локальном клоне, что приводит к быстрым клонам и сохраненному дисковым пространствам.

Или это именно то, как вы настроили свою работу, и не собираете последние коммиты? Если это так, просьба предоставить более подробную информацию. Рассмотрите возможность публикации конфигурации своей работы.

Ответ 2

Посмотрите на плагин рабочей области для клонирования. Вы можете либо использовать это, либо настроить задание для обновления локального репозитория от Github, а затем выполнить все остальные задания из этого локального репо.

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

Ответ 3

У меня был такой же опыт.

У меня есть одно задание потянуть реальное дистанционное репо, которое является github.

У каждого из других заданий (их много) есть "URL-адрес репозитория", например:

file:///C:/Program Files (x86)/Jenkins/jobs/webtest-local-repo/workspace/.git

Он клонирует штраф, но последующие выборки не замечают никаких изменений.

Такая же проблема возникает в gitbash, поэтому я предполагаю, что это проблема git, а не проблема jenkins.

Мое ужасное обходное решение заключалось в том, чтобы заставить зависимые задания удалять свои рабочие пространства при завершении построения, так что каждая операция git является "клоном". Это смешно, но, возможно, менее смешно, чем иметь миллион рабочих мест, ударяющих в то же самое репозитование github.

ZOMG! Это тоже не сработало, потому что в то время как git может успешно клонировать репо, дженкинс запомнит предыдущую ревизию и снова построит тот же самый. Возможно, это связано с этой проблемой, я не знаю, мне очень надоело. Мы сдались, и теперь все рабочие опросы github снова. Возможно, вместо этого я найду крючок.