Как заставить Дженкинса пропустить нисходящую работу, если новая сборка ждет в трубопроводе?

Мой строительный трубопровод в Дженкинсе разбит на три задания:

Код сборки
Развертывание кода для среды
Запуск автоматизированных функциональных тестов

Я настроил его так, чтобы возникали параллельные сборки, и конвейер сборки останавливает сборку из ввода # 2, если в настоящее время выполняется # 2 или # 3 для другой сборки.

То, что я хочу сделать, - это настроить Jenkins для обработки, когда есть несколько ожиданий построения, а # 2 и # 3 - только для того, чтобы только LATEST build входила в # 2 и # 3.

Есть ли способ сделать это из коробки? Если у вас есть книга "Непрерывная доставка", то, что я пытаюсь сделать, это реализовать то, что на p. 118 - стр. 119

Ответ 1

Попробуйте один из них в разделе Дополнительные параметры проекта:

Блокировать сборку, когда проект upstream строится
(должен убедиться, что он не вызывает шаги 2 и 3, чтобы застрять в очереди)
Блокировать сборку, когда проект downstream строится
(Я знаю, что это звучит как противоположность вашему запросу, но фактический результат заключается в том, что вы накапливаете изменения в единый цикл сборки, предотвращение дополнительных прогонов)

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

Остановка работы Дженкинса при запуске более новой версии (malenkiy_scot)
Плагин очереди очистки для очистки
Убийца сигналов

Убить все сборки (любезно предоставлено Kohsuke Kawaguchi)

import hudson.model.*;

Hudson.instance.computers.each { c ->
  c.executors.each { e ->
     e.interrupt();
  } 
}

Приветствия

Ответ 2

Плагин Workflow позволяет писать весь конвейер как один script. В этом случае шаг stage может использоваться для управления доступом:

stage 'build'
// any number of builds get here
stage name: 'deployAndTest', concurrency: 1
// only the last to build successfully enters here

(Для целей визуализации JENKINS-29892 позволит вам пометить границу между этапами deploy и test.)

Ответ 3

Проблема с "block upstream" или "block downstream" заключается в том, что вы всегда блокируете что-то, что может работать.

Если вы используете "git", вы можете сделать что-то в этих строках - это, случается, то, что я делаю...

Я использую ветвь отслеживания, которая указывает на последнее завершенное задание сборки любого шага, называемого следующим образом: <branch>-latest-<step>. Итак, если вы запустите шаг "build" на основе мастера, вы получите master-latest-build. Очень легко переместить эту ветвь в конец вашей сборки script, просто запустите: git branch -f <name> HEAD, а затем нажмите.

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

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

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