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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

**ZOMG!** Это тоже не сработало, потому что, хотя git мог успешно клонировать репо, jenkins запомнил предыдущую ревизию и снова собрал ту же самую. Возможно, это связано с[Эта проблема](http://jenkins.361315.n4.nabble.com/how-to-build-a-specific-git-branch-with-jenkins-td4576864.html)Я не знаю, я сыт по горло. Мы сдались, и теперь все рабочие места снова опрашиваются. Может быть, я получу зацепку вместо этого.



[Плагин Clone Workspace](https://wiki.jenkins-ci.org/display/JENKINS/Clone+Workspace+SCM+Plugin), Вы можете использовать это или настроить задание для обновления локального репозитория с Github, а затем получить все остальные задания из этого локального репо.

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