Я думаю try and catch  правда я и в jenkins  еще не юзал но спасибо огромное за наводку

обернуть pipeline в try catch
В catch искать последнюю успешную сборку. Что-то типо

    def build = currentBuild.rawBuild
    while (true) {
        try {
             build = build.getPreviousBuild()        
            if (hudson.model.Result.SUCCESS.equals(build.getResult())) { break  }
        } catch (e) {
            println "error get previousBuild"
            println e.message
            throw e
        }
    }

А у всех такая большая разница между запуском сборки на обычном агенте и агенте в k8s?

С момента запуска до выполнения первой команды в обычном агенте проходит 2-3 секунды, в кубе секунд 60
Это при том что образ jnlp агента не скачивается, поскольку он уже есть локально на воркере.

Смущает то, что с момента старта pipeline. Время теряется не на старте пода агента и подключения его к jenkins. С этим ничего не поделаешь. А некие промежутки времени, которые тратятся непонятно на что.

Например

Начнем с самого начала

17:07:17  [Pipeline] Start of Pipeline
17:07:18  [Pipeline] podTemplate
17:07:18  [Pipeline] {
17:07:19  [Pipeline] node
17:07:28  Created Pod: kubernetes jenkins/infrastructure-test-7-5kfpp-3prkq-41qn1

C момента старта пайплайна до отправки запроса на создание пода может проходить  3-20 секунд (непонятно от чего это время зависит), в данном случае это заняло 11 секунд.

Запрос на создание пода отправляется именно тогда, когда jenkins пишет Created Pod, это видно по логам kube-apiserver

I0423 17:07:28.431367       1 httplog.go:90] POST /api/v1/namespaces/jenkins/pods/infrastructure-test-7-5kfpp-3prkq-41qn1/binding: (4.876409ms) 201

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

2021-04-23T17:07:33.922200683+03:00 INFO: Trying protocol: JNLP4-connect
...
2021-04-23T17:07:37.577473001+03:00 Apr 23, 2021 12:07:37 PM hudson.remoting.jnlp.Main$CuiListener status
2021-04-23T17:07:37.577504166+03:00 INFO: Connected

Мастер же раздупляется только еще через 11 секунд (17:07:48)

17:07:35  Still waiting to schedule task
17:07:35  ‘infrastructure-test-7-5kfpp-3prkq-41qn1’ is offline
17:07:48  Agent infrastructure-test-7-5kfpp-3prkq-41qn1 is provisioned from template Infrastructure_test_7-5kfpp-3prkq

Далее он еще три секунды чего-то думает и наконец радостно сообщает

17:07:51  Running on infrastructure-test-7-5kfpp-3prkq-41qn1 in /home/jenkins/agent/workspace/Infrastructure/test

Но не тут то было, он почему-то опять долго думает (17 секунд) прежде чем начать выполнять первую команду:

17:07:51  Running on infrastructure-test-7-5kfpp-3prkq-41qn1 in /home/jenkins/agent/workspace/Infrastructure/test
17:07:51  [Pipeline] {
17:07:51  [Pipeline] stage
17:07:52  [Pipeline] { (test)
17:07:52  [Pipeline] sh
17:08:08  + echo Hello
17:08:08  Hello

Итого: 11 + 11 + 3 + 17 = 42 секунды ушли не совсем понятно куда (это еще неплохой кейс, там бывает и 60-70 секунд). А 9 секунд на старт пода агента, его инициализацию и подключение к jenkins.

Может показаться 42 секунды не так много, но как-то обидно их терять на ровном месте особенно сверху над тем, что еще нужно время на запуск пода и подключение его к jenkins. А когда под боком есть обычные агенты и там со старта пайплайна до запуска первой команды проходит 3 секунды, то совсем грустно.

Это у меня одного такие проблемы или все просто смирились с этим? Или может не юзают агенты в kubernetes?
@s2504s помню ты уже жаловался давно на это, ты это так и не решил или забил или не юзаешь плагин?

Хотя 42, это же  ответ на главный вопрос жизни, вселенной и всего такого 🤔 тогда все сходится

У меня чуть в другом месте затык бывает. Когда дженкинс не находит свободных агентов (естесственно - так как поды убиваются после завершения джобы) он пишет

16:21:26  All nodes of label ‘build-service-pod’ are offline
16:21:29  Created Pod: jenkins/build-service-pod-64564-z82cw

И вот между этими 2-мя шагами бывает до 5-ти минут

Многие жалуются на тормоза при старте в кубах. Общего решения нет. Надо дебажить с обоих сторон

Проблема в дженкинсе. Вернее в том как он обсчитываетвремя ожидания для спавнинга гового агента

Просто тот кластер где это все происходит - он тестовый. Никакой нагрузки там нет. И если создать под через кубцтл - то на все уходит 2 секунды

ну тут очевидно проблема в плагине.
Так как я вижу в пайплайне

17:07:28  Created Pod: kubernetes jenkins/infrastructure-test-7-5kfpp-3prkq-41qn1

в kube-apiserver в эту же секунду запрос успешно выполняется

I0423 17:07:28.431367       1 httplog.go:90] POST /api/v1/namespaces/jenkins/pods/infrastructure-test-7-5kfpp-3prkq-41qn1/binding: (4.876409ms) 201

Через 9 секунд я вижу готовый, запущенный и подключенный к jenkins  агент:

2021-04-23T17:07:33.922200683+03:00 INFO: Trying protocol: JNLP4-connect
...
2021-04-23T17:07:37.577473001+03:00 Apr 23, 2021 12:07:37 PM hudson.remoting.jnlp.Main$CuiListener status
2021-04-23T17:07:37.577504166+03:00 INFO: Connected

Что тут еще со стороны куба можно улучшить, 9 секунд меня устраивают да и в целом подождать если там новый тяжелый образ тоже норм. Но плюсом к ним еще какие-то тормоза почти в минуту как-то удручают.

вобщем понятно, не у одного у меня такие проблемы. @s2504s  @dburm спасибо

> C момента старта пайплайна до отправки запроса на создание пода может проходить  3-20 секунд (непонятно от чего это время зависит), в данном случае это заняло 11 секунд.

Я в код самого дженкинса не смотрел, может быть он там по таймеру приходит в очередь на создание новых агентов? Например раз в 30 секунд..

Там структура кода довольно читабельная. Можно посмотреть

Да надо смотреть походу и дебажить

Абстарактный вопрос. Вкатываемся в jenkins pipeline
Что лучше пользовать scripted or declarative?

В доке вроде пишут что декларатив мейнстрим, но куча советов что скриптовый лучше)

Декларатив - это когда у вас 2 стейджа, один из которых загрузка кода). Все равно всю логику будете городить внутри script {}

Мы вот тоже пошли по пути декларатива) Но полезных плюх пока не нашли. Правда у нас ветвистая логика сборки проекта

Тоже заметил такое
Больше всего мне понравился в декларативе функционал post(и options)
Но вчера обнаружилось, что он косячный и пост для стейджа завист от состояния всего билда(

Видимо придется переписать на скриптовый, благо не очень много пока)

еще и переиспользование стейджей и даже всего пайплайна. В декларативе с этим есть нюансы (