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

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

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

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

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

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

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

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

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

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

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

Ответы на вопрос(3)

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

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

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

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

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

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

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

Решение Вопроса

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

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

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

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

 Malcolm Box02 апр. 2012 г., 15:26
Спасибо - это похоже на то, что я ищу! Я пойду проверить ...
 sti09 авг. 2016 г., 19:16
Я не уверен, но я думаю, что нужен абсолютный путь. Имя задания не имеет значения в файловой системе, особенно на ведомом.
 AlexeiOst25 авг. 2015 г., 20:16
Это отлично! Кажется, работает хорошо.
 demaniak02 июн. 2016 г., 22:07
Как выглядит этот путь? То есть это абсолютный путь к файловой системе? Могу ли я использовать другое имя задания в качестве корня пути?
 sti27 мая 2014 г., 23:36
Просто хотел уточнить: похоже, что последний плагин git теперь имеет всплывающее меню с дополнительными опциями, а справочное хранилище находится в разделе «Расширенное поведение клона».

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

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

 Malcolm Box29 мар. 2012 г., 10:53
Я использую триггер "Построить после" на вторичных сборках
 Lars Kotthoff29 мар. 2012 г., 18:30
Вы смотрели журналы на что-нибудь подозрительное?
 Lars Kotthoff29 мар. 2012 г., 09:41
Как вы запускаете сборки? Вы пробовали опрашивать местный репо и проверять журнал опроса?
 Malcolm Box28 мар. 2012 г., 23:34
Я меньше беспокоюсь о дисковом пространстве, и в любом случае я считаю, что git умный и использует ссылки, где это возможно, при клонировании локального репо. Я хочу сделать все остальные задания из локального репо, но я не могу понять, как это сделать. Кажется, что они не тянут новые коммиты даже через локальный репозиторий.

Ваш ответ на вопрос