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

Question

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

Это занимает как дисковое пространство, так иbandwidth.

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

Пока чтоработает "Обновить локальное репо" - он успешно клонируется, и если я иду в рабочую область, я вижу, что у него есть коммит HEAD origin / master.

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

У меня есть одна работа, чтобы вытащить настоящее удаленное репо, это github.

Каждое из других заданий (их много) имеет «URL хранилища», например:

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

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

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

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

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