В рамках сборки заданий Jenkins, используя сценарий Groovy, мы можем динамически создавать новые задания. Подробнее о this .
У нас есть архитектура с одним главным и n-подчиненными узлами.
Мы создаем любое задание Jenkins (скажем, some-pipeline-job
) который настраивается на главном Jenkins очевидно .
При запуске сборки этого задания (some-pipeline-job
) сборка может выполняться на любом подчиненном узле.
Последствия:
1) Эта сборка задания (some-pipeline-job
) создает рабочее пространство для каждой сборки, которая может выполняться на любом подчиненном узле
2) Это задание (some-pipeline-job
) имеет код Groovy для создания нового динамического задания c (скажем, job23
) во время выполнения в среде его сборки
Цель:
Управление дисками рабочих пространств любой сборки задания на подчиненных узлах с использованием второго шага, упомянутого в этой процедуре , на основе некоторых критериев, таких как сборки numberOfDaysOld, et c ...
1)
Может ли второй шаг, упомянутый в cloudbees-support , позаботиться об очистке рабочих пространств для всех сборок заданного c задания (some-pipeline-job
) работать на нескольких подчиненных узлах Jenkins?
2)
Есть ли у главного Jenkins информация об этом динамическом c задании (job23
), созданном some-pipeline-job
, во время выполнения? Как я могу убедиться, что задание Dynami c отслеживается (настраивается) в главном Jenkins?
3)
Если да, может ли этот второй шаг, упомянутый в cloudbees-support? позаботиться об очистке рабочего пространства job23
build?