Выполнение одной сборки для одного коммита в Jenkins/Hudson

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

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

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

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

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

ОТВЕТЫ

Ответ 1

Еще нет, есть Feature Feature, охватывающий этот вид сборки, но он все еще открыт: Проблема 673

Ответ 2

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

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

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

  • разработчик 1 звезда новый филиал, чтобы сделать его изменения, на основе нашей основной отрасли развития
  • Разработчик 1 совершает так часто, как ему нравится
  • разработчик 1 считает, что он закончил свою работу, он объединяет свои изменения в одно изменение и подталкивает его к gerrit.
  • Создается новое изменение gerrit, и jenkins пытается построить точно это изменение
  • Если во время сборки нет ошибок, в этом изменении делается обзор.
  • Когда просмотр отправляется, набор изменений объединяется в ветку разработки основного репозитория (без изменений в ветку разработки без проверки)
  • Jenkins строит объединенную версию, чтобы убедиться, что нет ошибок слияния

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

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

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

Мы используем это для нашей разработки С# - на окнах не на linux

Ответ 3

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

Вот учебник по этой теме: Тихая функция периода.

Ответ 4

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

Ответ 5

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

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

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

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

Ответ 6

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