Как я могу запустить задание Jenkins после завершения набора других заданий?

Простой случай, когда у вас есть только одно задание, зависящее от завершения набора других заданий, прост: либо используйте многозадачность, либо используйте плагин потока сборки с parallel { ... }. Случай, который я пытаюсь решить, более общий, например:

JobA depends on JobX and JobZ
JobB depends on JobY and JobZ
SuperJob depends on JobA and JobB

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

Похоже, что ни плагин потока сборки, ни плагин соединения, ни плагин задания DSL не имеют для этого хорошего механизма. Я могу, конечно, просто запустить все свои задания и попросить их опросить Дженкинса, но это было бы довольно уродливо.

Еще один тупик — это «триггер задания вверх по течению». Я хочу инициировать конкретную сборку задания, а не просто любой запуск восходящего задания.

обновить

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

left1 (1m)  right1 (55m)
   |            |
left2 (50m) right2 (2m)
   |____________|
         |
        zip

С плагином multijob вы получаете:

Phase 1:
   left1, right1  // done in 55m
Phase 2:
   left2, right2  // done in 50m
Phase 3:
    zip   // total time 105m

Если бы у меня был способ инициировать следующее задание точно после того, как все предварительные условия выполнены, то общее время сборки составило бы всего 57 минут.

Ответ здесь должен объяснить, как я могу добиться такого поведения, желательно без написания собственного механизма опроса.

обновление 1 1/2 В комментариях ниже было предложено сгруппировать левые и правые задачи в одну подзадачу. Да, в данном примере это можно сделать, но сделать это вообще и автоматически очень сложно. Например, предположим, что есть дополнительная зависимость: right2 зависит от left1. При заданном времени сборки оптимальное время сборки не должно меняться, так как левая1 выполняется задолго до того, как запустится правая2, но без этих знаний уже нельзя смешивать левые1 и левые2 в одной группе, не рискуя не иметь прав1 имеется в наличии.

обновление 2

Похоже, здесь нет готового ответа. Кажется, мне придется самому написать системный скрипт groovy. Смотрите мой собственный ответ на вопрос.

обновление 3

В итоге мы разветвили плагин multijob и написали в нем новую логику. Я надеюсь, что мы сможем опубликовать его как новый плагин после некоторой очистки...


person Christian Goetze    schedule 21.09.2015    source источник
comment
Пожалуйста, укажите решение, если вы его найдете.   -  person Ronak Agrawal    schedule 22.09.2015
comment
Подано issues.jenkins-ci.org/browse/JENKINS-30580, но Я боюсь, что мне придется самостоятельно кодировать некоторые опросы... Можно, например, просто запустить все задания сразу, а затем заставить их ждать. Может быть, можно использовать исполнителей-приспособленцев для опроса, а затем заставить их запустить настоящую вещь, как только опрос завершит, что все предварительные требования выполнены.   -  person Christian Goetze    schedule 22.09.2015
comment
gist.github.com/cg-soft/0ac60a9720662a417cfa — мое решение, см. также ниже .   -  person Christian Goetze    schedule 05.10.2015


Ответы (4)


Поскольку вы добавили тег jenkins-workflow, я думаю, что использование плагина рабочего процесса Jenkins вам подходит, поэтому, возможно, этот сценарий рабочего процесса соответствует вашим потребностям:

node {
    parallel left: {
        build 'left1'
        build 'left2'
    }, right: {
        build 'right1'
        build 'right2'
    },
    failFast: true

    build 'zip'
}

Этот рабочий процесс запустит zip, как только закончатся обе параллельные ветви.

person amuniz    schedule 25.09.2015
comment
Я думаю, вам нужно использовать задания left1/left2/right1/right2 во втором примере, так как в вашем решении вы запускаете JobZ дважды. Но это поднимает второй вопрос, а именно то, что разделение графа зависимостей на непересекающиеся части не всегда возможно, как показано в первом примере. Расширяя второй пример, предположим, что left2 зависит от right1 в дополнение к существующим зависимостям, это также предотвратит любую попытку разделения. - person Christian Goetze; 25.09.2015
comment
Тогда я думаю, что это еще проще, просто используйте параллель и сразу после этого создайте окончательную работу (см. Оригинальный скрипт, обновленный в моем ответе). - person amuniz; 26.09.2015
comment
Пожалуйста, прочтите пример еще раз и подумайте... Проблема не в том, что вы не можете сгенерировать правильный поток сборки. Проблема в том, что ожидание завершения всех заданий в первой фазе до начала второй фазы ужасно неэффективно, особенно когда есть много заданий и много фаз. Вы почти гарантированно получите наихудшее время выполнения. - person Christian Goetze; 26.09.2015
comment
Действительно? Учитывая ваш пример времени для левого и правого, я бы сказал, что мое предложение займет 55 + время почтового индекса (что является оптимальным временем), поскольку параллельные ветви работают - очевидно - параллельно. Обратите внимание, что я говорю не о параллельном шаге в плагине BuildFlow, а в плагине Jenkins Workflow. - person amuniz; 30.09.2015
comment
Предположим, что есть дополнительная зависимость: right2 зависит от left1. Как бы вы представили эту сборку? Как бы вы разрешили произвольный граф зависимостей? - person Christian Goetze; 30.09.2015
comment
В ожидании JENKINS-27127 этот сценарий будет немного сложнее писать, но уже можно использовать waitUntil, как указано в этом выпуске. - person Jesse Glick; 29.10.2015

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

Этот смысл реализует мое решение, включая правильную обработку отмены заданий: https://gist.github.com/cg-soft/0ac60a9720662a417cfa

person Christian Goetze    schedule 25.09.2015
comment
Я не очень доволен этим решением, так как у него есть свой набор проблем — в частности, как отображать прогресс и как безопасно справляться с отменами, но я не вижу ничего лучше, кроме, может быть, перехода на TeamCity :) - person Christian Goetze; 01.10.2015
comment
Суть решает проблему отмены, но создание красивого дисплея все еще не в моих силах... буду работать над этим. - person Christian Goetze; 06.10.2015
comment
Я собираюсь отменить ответ на свой ответ. В больших масштабах опубликованный сценарий приведет к сбою Jenkins. Я понятия не имею, как это отладить. Может показаться, что мои вызовы создают множество объектов, быстро заканчивая память. - person Christian Goetze; 16.11.2015

Вы можете использовать Build other projects как Post Build Actions в конфигурации одного из ваших родительских заданий, что вызовет запуск второго родительского задания при успешной сборке задания. Когда второе родительское задание также будет завершено, запустите дочернее задание тем же методом.

person Gursimran Singh    schedule 21.09.2015
comment
Извините, но нет :) Это потребовало бы от меня линеаризации сборки. Я хочу столько параллелизма, сколько позволяет граф зависимостей. На некоторых моих работах 50 родителей, я не собираюсь казнить 50 родителей одного за другим. - person Christian Goetze; 22.09.2015
comment
В этом случае вам потребуется программно опросить его настраиваемым способом, поскольку в Jenkins нет такого плагина, который мог бы решить вашу задачу как таковую. - person Gursimran Singh; 22.09.2015
comment
Вот вы говорите, а может кто-то уже построил что-то для себя, и может быть готов с этим расстаться, а может есть непонятная конструкция о которой я не знаю. В том то и смысл, что я спрашиваю. Насколько я могу судить, похоже, мне нужно написать собственное решение для опроса, но я бы предпочел этого не делать, если можно этого избежать. - person Christian Goetze; 22.09.2015

плагин Multijob можно использовать для создания иерархии заданий.

Сначала выберите Multijob Project в новом элементе, а затем в конфигурации вы можете добавить столько заданий, сколько хотите. Вам также необходимо указать фазу для каждого задания.

person Triangle    schedule 22.09.2015
comment
Я уже упоминал об этом в тексте вопроса: на первом этапе вы строите все без каких-либо зависимостей. На этапе 2 вы строите все, что требует только этапа 1, на этапе 3 вы строите все, что требует только этапа 1 и 2 и т. д. Я отредактирую вопрос, объясняющий, почему этот алгоритм в худшем случае является нормальным случаем и почему он недостаточен. - person Christian Goetze; 22.09.2015