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

Question

Есть 4 вакансии:

Build1  
Build2  
Test1  
Test2

Build1 и Build2 могут быть запущены одновременно.
Test1 должен запускаться только тогда, когда оба Build1 и Build2 будут завершены. Tes2 должен быть запущен только тогда, когда Tes1 будет завершен.
Также мне хотелось бы иметь возможность запускать все эти задания отдельно.
Есть ли способ настроить задания в соответствии с этими правилами?

Answer 1

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

Этот параметр находится в Триггеры сборки -> Построить после того, как другие проекты собраны при создании / изменении задания.

Answer 2

Я думаю, у вас есть несколько вариантов. Я предполагаю, что мы говорим о долго выполняющихся заданиях, иначе я бы просто связал их вместе как одно задание монстра (несколько этапов сборки в одном задании) и создал отдельные задания для запуска их по отдельности.

Как уже упоминалось, для длительных заданий посмотрите на плагин join . Как общий FYI есть страница, объясняющая, почему вы хотите отделить задания по тестированию от работ по сборке. Смотри здесь .

Answer 3

«Плагин Promoted Builds» может быть хорошим решением: вы можете настроить основное задание «Build» так, чтобы оно ничего не делало, кроме запуска 2 последующих сборок «Build1, Build2» (в действиях после сборки). Затем вам нужно добавить процесс продвижения «Когда следующие последующие проекты будут успешно собраны», выбрав «Build1, Build2», с соответствующим последующим действием сборки «Test1». Если «Build1» и «Build2» собираются успешно (оба состояния STABLE), «Build» будет повышен, а «Test1» будет поставлен в очередь. Наконец, вы запускаете Test2 как действие Test1 после сборки.

Но вы должны знать, что в случае, когда многие экземпляры «Build» поставлены в очередь, вы не можете полагаться на постоянную ссылку на последнюю успешную сборку (следующая «Build1» или «Build2» может быть уже создана, когда «Test1» вызывается сначала появится «Build» из очереди), и вам придется придумать способ отслеживать ревизию тестируемой вами сборки.

Параметризованный плагин триггера может помочь в решении этой проблемы: например, вы можете передать идентификатор восходящей сборки в качестве параметра.

Answer 4

Вы можете сохранить свои Test1 и Test2 как отдельные задания, вместо того, чтобы быть частью сборок.

Когда Build1 и Build2 завершены, Test1 может начаться как последующая сборка.Test2 может быть последующим заданием из Test1.

Answer 5

Я использую версию 1.346 Hudson.

Вы можете выбрать «Построить после сборки других проектов» в разделе «Построить триггеры».

В нем говорится, что «Можно указать несколько проектов, например« abc, def »»

Таким образом, вы должны иметь возможность добавить 'Build1, Build2' в это поле в конфигурации для Test1.