Отключить одновременные сборки

История: мы ищем решение по оптимизации нашей конвейерной обработки (бывший рабочий процесс).

В настоящее время мы запускаем несколько параллельных развертываний и тестов, распределенных по 2 сборщикам, по 4 исполнителя в каждом.

Конвейер запускается отправкой Git, поэтому последующие отправки запускают несколько сборок. Мы поэкспериментировали с вариантом параллелизма этапов: 1, который красиво блокирует шаг последующей сборкой, но активируется, когда этот конкретный этап завершен.

Вопрос(ы):

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

Q1: Является ли это лучшей практикой?

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

См. конфиг первого этапа [1]

[1] первый этап..

stage name: 'Checkout and build WAR'
node {
    def mvnHome = tool 'Maven 3.2.x'
    checkout([$class                           : 'GitSCM',
          poll                             : true,
          branches                         : [[name: '*/master']],
          doGenerateSubmoduleConfigurations: false,
          extensions                       : [[$class           : 'RelativeTargetDirectory',
                                               relativeTargetDir: 'checkout-directory']],
          submoduleCfg                     : [],
          userRemoteConfigs                : [[url: 'https://some.repo/repo.git']]])

// Archive the cloned repo.
stash name: 'src', includes: 'checkout-directory/war/src/, checkout-directory/war/pom.xml'

// Run without tests, do the unit and integration tests in a separate stage.
sh "${mvnHome}/bin/mvn -f checkout-directory clean install -DskipTests"

// Archive the application build.
stash name: 'war', includes: 'checkout-directory/war/target/*.war'
}

person user1794565    schedule 20.04.2016    source источник
comment
Смотрите мой ответ здесь: stackoverflow.com/questions/36454130/   -  person Vladimir Rozhkov    schedule 08.07.2016


Ответы (2)


Из задания configuration вы можете установить:

  • Выполнение параллельных сборок при необходимости
  • Тихий период

Если установлено, новая запланированная сборка ожидает столько же секунд, прежде чем будет построена. Это полезно для:

  • Объединение нескольких сообщений электронной почты с уведомлением об изменениях CVS в одно (некоторые сценарии генерации сообщений электронной почты журнала изменений CVS генерируют несколько сообщений электронной почты в быстрой последовательности, когда фиксация охватывает несколько каталогов).
  • Если ваш стиль кодирования таков, что вы фиксируете одно логическое изменение за несколько операций cvs/svn, то установка более длительного периода молчания не позволит Jenkins создать его преждевременно и сообщить об ошибке.
  • Дроссельные сборки. Если ваша установка Jenkins слишком загружена слишком большим количеством сборок, установка более длительного периода простоя может уменьшить количество сборок.

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

Что касается jenkins-pipeline DSL, эта статья ответит на ваш вопрос. :

По умолчанию сборки Pipeline могут выполняться одновременно. Команда stage позволяет пометить определенные разделы сборки как ограниченные ограниченным параллелизмом (или, позже, неограниченные). Более новые сборки всегда имеют приоритет при переходе на такой ограниченный этап; более старые сборки просто завершатся раньше, если они будут упреждены.

person luka5z    schedule 20.04.2016
comment
Ах .. спасибо. Конечно, обычная конфигурация задания может предвосхитить параллелизм. Я исходил из DSL-скрипта, который, видимо, на это не способен. Параметр параллелизма: 1 на этапе не сокращает его, потому что, когда этот конкретный этап будет выполнен, он войдет в параллельную сборку. - person user1794565; 21.04.2016
comment
По состоянию на 17 августа параметр параллелизма команд stage устарел и больше не должен использоваться. Альтернативный подход — использование шага milestone, который не препятствует запуску сборок, а просто ждет предыдущей сборки. - person Jazzschmidt; 04.09.2017
comment
Простите, я хотел сказать lock шаг. - person Jazzschmidt; 04.09.2017

Использование конфигурации Jobs через свойства кажется самым чистым способом.

См. https://stackoverflow.com/a/43963315/1756183.

person dag    schedule 30.05.2017