охренеть у вас объемы, конечно

ну и да, попробуйте запараллелить подпись если это возможно

как минимум собственная очередь

вариант с несколькими джобами — в принципе вариант, но оно как-то... раздробленно выглядеть начинает. Ну типа, в случае обычного пайплайна со стейджами я могу хоть как-то "в целом" на него посмотреть, есть один общий лог, есть одно общее место в котором показывается, что сколько выполнялось. А тут получается, что я открыл билд, начал смотреть на лог, дошёл до точки Х — процесс завершён, но не до конца, извольте проследовать в другой джоб.
Я могу конечно сварить аггрегирующий джоб типа

stage('build') { built = runJob('build') }
stage('sign') { signed = runJob('sign', parameters=built.artifacts) }
stage('package') runJob('package', parameters=signed.artifacts) }

, но как-то всё равно оно странно смотрится 🤔

может быть я конечно смотрю на мир зашорено, и для истинного дзена нужно использовать дженк только для автоматизации, а для логов и прочей метрики выстраивать вокруг него ELK, prometheus и прочая-прочая, но тем не менее

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

к чёрту детали!) Я на это сейчас в более абстрактном виде смотрю:
- сборка состоит из шагов 1, 2 и 3
- шаг 1 может выполняться где угодно и создаёт наборы файлов А и Б
- шаг 2 — на одной-единственной ноде, и ему нужен набор Б от шага 1, который он преобразует в Б2
- шаг 3 — где угодно, и ему нужны наборы А, Б2
- 1 по длительности сопоставимо с 2

сейчас всё это 1 2 3 выполняется в виде фристайла, подряд, на одной ноде, хотя в теории могло бы и на нескольких. Ну и вопрос в том, как может выглядеть пайплайн, который выполняет 1 на любой из нескольких нод, и 2 на одной конкретной, чтобы простаивания ресурсов получалось по минимуму

Подскажите, как можно сделать счетчик прохождения определенного stage в сборке?

Счетчик?

ну да, на входе поступает n-ое количество объектов для которых должна выполниться сборка. Так вот, для некоторых она не выполняется по условию if и должен быть exception. Так вот нужно посчитать количество и промаркировать результат сборки нужным статусом

ну так и делайте все в пайплайне

глобальную переменную инкрементировать, м?

Всем привет, у меня есть несколько pipeline’ов в которых дублируются шаги, ткните носом, пожалйуста, как это грамотно унифицировать, чтобы не копипастить в несколько мест.

shared library —> vars

вынести в функции

всем привет
кто-нибудь знает как это убрать?

Коллеги. Есть какие то контраргументы против держать всю логику пайплайна в shaed library и из пайплайна ее только вызывать как функцию (ну может еще параметры пробрасывать в нее)?

Никаких по мне)

можно пойти дальше, и отказаться даже от вызовов.
дёргать пайплайн напрямую из проекта с либами

дергать пайплайн из репы с shared library?

Точка входа все равно ведь должна быть, не?