Задание семян Jenkins, которое выполняет только DSL-скрипты, измененные с момента последнего запуска?

Question

У меня есть несколько репозиториев исходного кода, содержащих различные биты кода, созданные Jenkins, с сопоставлением «один к одному» между заданиями Jenkins и исходными репозиториями. Отдельно от них у меня есть один репозиторий, содержащий сценарии работы DSL для создания/обновления заданий Jenkins, которые создают другие репозитории. Ситуация выглядит примерно так:

Я надеялся найти способ сохранения работы DSL сценариев в отдельных хранилищах исходного, прямо рядом с кодом, и есть одно задание семян, что бы быть запущена путем push-уведомлений до любых других репозиториев. К сожалению, похоже, что в настоящее время он недостаточно хорошо поддерживается (см. Принятый ответ на this question). Учитывая, что сейчас просто проще оставить все DSL в одном отдельном репозитории и позволить push-уведомлениям в этот репозиторий инициировать повторную обработку строчных скриптов. И все работает отлично, более или менее.

Тем не менее, я немного обеспокоен тем, что начальное задание - при запуске - перезапускает все сценариев DSL, а не только те, которые действительно изменились. (Я честно не уверен, что это «проблема», сама по себе, я просто опасаюсь, что позже это может привести к неожиданному поведению.)

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

Answer 1

Работа DSL будет только обновлять задание, если сгенерированная конфигурация изменится. Он сравнивает сгенерированный XML с существующей конфигурацией, чтобы узнать, требуется ли обновление. См. JenkinsJobManagement.java. Поэтому, если вы не меняете задания вручную или запускаете вредоносные плагины, которые изменяют конфигурацию задания в фоновом режиме, при повторном запуске скриптов не должно возникнуть никаких проблем.

И Job DSL повторно использует механизм сценария Groovy при запуске нескольких сценариев, поэтому влияние производительности должно быть низким. См. DslScriptLoader.groovy.

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