Внедрение одной сборки для одного коммита в Дженкинс / Хадсон

Question

Мы используем Jenkins для выполнения пошаговых сборок нашего проекта при каждом коммите в SCM.Мы хотели бы получить отдельные сборки для каждого коммита.Однако наивный подход (настройка SCM и использование перехватов после фиксации для запуска сборки) создает проблему в следующем сценарии:

• Сборка запускается.
• Во время сборки (это может занять несколько минут) две отдельные фиксации в SCM выполняются двумя разработчиками.
• Одна новая сборка запущена.Он получает изменения от обоих коммитов, сделанных во время предыдущей сборки.

Это "состояние гонки" усложняет поиск того, какой из коммитов нарушил сборку / введенные предупреждения.

используемое в настоящее время решение проверяет изменения в одном задании («задание планировщика») и запускает другое задание для фактической проверки и сборки.

Существуют ли надлежащие решения этой проблемы?

Answer 1

Пока нет, есть запрос функции, охватывающий этот тип сборки, но он все еще открыт: Выпуск 673

Answer 2

Может быть, это упускает из виду, но у нас здесь довольно хороший процесс сборки.

• Мы используем git в качестве системы контроля версий
• Мы используем Gerrit в качестве инструмента для обзора
• Мы используем триггер gerrit для запуска сборок на нашем сервере jenkins
• Мы проверяем изменения в ветви разработки для запуска jenkins при объединении набора изменений

Короче говоря, идеальный день разработчика выглядит так

1. разработчик 1 создает новую ветку для своих изменений, основываясь на нашей основной ветке разработки
2. Разработчик 1 совершает так часто, как ему нравится
3. разработчик 1 думает, что он закончил свою работу, он объединяет свои изменения в одно изменение и подталкивает их к зародышу
4. Создано новое изменение геррита, и Дженкинс пытается построить точно это изменение
5. Если при сборке нет ошибок, делается обзор этого изменения
6. Когда рецензия отправляется, ревизия объединяется с ветвью разработки основного репозитория (без слияния в ветку разработки без рецензирования)
7. Jenkins создает объединенную версию, чтобы быть уверенным, что ошибок слияния нет

ни один разработчик 2 не вступает в партию и не пытается что-то сделать

процесс точно такой же, и оба начинают работать, там ветки. Разработчик 1 работает быстрее, и его изменения объединяются в ветке разработки. Теперь, прежде чем разработчик 2 сможет опубликовать свои изменения, он должен отменить свои изменения поверх изменений, внесенных разработчиком 1.

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

Мы используем это для нашей разработки на C # - на Windows, а не на Linux

Answer 3

Как указывал кто-то в Выпуск 673 , вы можете попробовать запустить параметризованную сборку с параметром, являющимся фактическим git commit, который вы хотите собрать. Это в сочетании с крюком фиксации VCS.

Answer 4

Если вы используете правило « NO COMMIT для сломанной сборки » и доведите его до логического завершения, вы фактически получите «No commit для сломанной сборки или сборки в процессе»,в этом случае описанная вами проблема исчезнет.

Позвольте мне объяснить.Если у вас есть два разработчика, работающих над одним проектом, и оба они пытаются зафиксировать (или нажать, если вы используете DVCS).Один из них будет успешным, а другие потерпят неудачу и должны будут выполнить обновление перед фиксацией.

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

Единственное, что может помешать вам использовать вышеуказанный подход, - это если сборка занимает слишком много времени., в этом случае вы можете обнаружить, что ваши разработчики никогда не получат шанса на коммит (это всегда сборка).Затем это драйвер для разделения вашей сборки на конвейер, состоящий из нескольких шагов, так что задание Post Commit занимает не более 5 минут, но в идеале - 1 минуту.

Answer 5

Я не верю, что вы хотели бы сделать это возможно.«Тихий период», упомянутый Даниэлем Кутиком, фактически используется, чтобы сообщить Хадсону / Дженкинсу, сколько времени ждать, чтобы позволить другим коммитам в том же проекте быть взятым.Значение: если вы установите это значение равным 60 секундам, и вы сделали коммит, он будет ждать минуту, прежде чем начинать новую сборку, что также даст время для других коммитов (в течение этой одной минуты).

Answer 6

Я думаю, что могло бы помочь, это установить Тихий период (Jenkins> Manage Jenkins> Configure System) на 0 и опрос SCM на очень короткое время.Но даже в течение этого короткого интервала может быть два коммита.На данный момент Jenkins не имеет возможности разбивать сборку на отдельные сборки на несколько SVN коммитов.

Вот учебник по этой теме: Функция Quiet Period * .