в configure такой же

declarative pipeline
post секция
может быть определена как под конкретным stage, так и общая для всего билда(из доки).
Есть способ сделать так, чтобы секция под stage зависела от статуса только этого stage,а не от общего currentBuild.currentResult ??

Если я не путаю ничего, статус билда= статус последнего стейджа, но из анстейбла в сакксесс перейти не может

если стейджы параллельно запущены, и какой-то из них меняет статус билда(например на USTABLE), то все post секции, запущенные позже по времени будут отрабатывать как UNSTABLE независимо от состояния самого стейджа

Лучше не завязываться на статус

нашел кучу "хотелок" по этому поводу, все объявлены "duplicated" для какого-то ISSUE(вообще слабопохожего на запрашиваемое), который закрыт со статусом "нет активности" ))

а на что завязываться, если мне по результату стейджа нужно, допустим, метки в МР гитлаба выставить )

или оповещение прислать)

отдельного стейджа, а не билда целиком

Трай-кетчи, собственный статус, что-то такое

это просто максимально костыльно )

Это Дженкинс)

размер пайпа раза в 3 увеличивается
куча if с проверкой "собственного статуса"
и catchError{
sh 'exit 1'
},
чтоб хоть как-то показать в Jenkins, что стейдж упал ))

Но вообще можно подумать о разделении пайплайна на несколько (запусков) если так много зависит от parallel

на пачку freestyle'ов, ага ))

Нет, просто вынести логику параллел в другой пайплайн и дергать этот с разными параметрами

тут ситуация вот такая
parallel (
 unit_test: { stage('unit')},
 func_test: { stage('func')},
 l18n_test: { stage('l18n')},
 etc
)
с абсолютно разной логикой
по сути никак не зависящие друг от друга

оберни просто нужный стейдж в try. И делай в cacth и finally для конкретного стейджа все что душе угодно.
Это же scripted, ты ничем не ограничен

Коллеги, подскажите пожалуйста с Jenkins. Застрял  на запуске воркер ноды. Воркер и мастер в  AWS EKS. При запуске воркера имею сл логи:
kubectl logs jenkins-build-agent-446x9-9v6j2 -n devops -c jnlp
Jun 03, 2021 3:04:25 PM hudson.remoting.jnlp.Main createEngine
INFO: Setting up agent: jenkins-build-agent-446x9-9v6j2
Jun 03, 2021 3:04:25 PM hudson.remoting.jnlp.Main$CuiListener <init>
INFO: Jenkins agent is running in headless mode.
Jun 03, 2021 3:04:25 PM hudson.remoting.Engine startEngine
INFO: Using Remoting version: 4.3
Jun 03, 2021 3:04:25 PM org.jenkinsci.remoting.engine.WorkDirManager initializeWorkDir
INFO: Using /home/jenkins/agent/remoting as a remoting work directory
Jun 03, 2021 3:04:25 PM org.jenkinsci.remoting.engine.WorkDirManager setupLogging
INFO: Both error and output logs will be printed to /home/jenkins/agent/remoting
Jun 03, 2021 3:04:25 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Locating server among [http://jenkins:8080/]
Jun 03, 2021 3:04:25 PM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: http://jenkins:8080/tcpSlaveAgentListener/ is invalid: 404 Not Found
java.io.IOException: http://jenkins:8080/tcpSlaveAgentListener/ is invalid: 404 Not Found
       at org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:222)
       at hudson.remoting.Engine.innerRun(Engine.java:693)
       at hudson.remoting.Engine.run(Engine.java:518)
Из настроек, передаваемых Дженкинсом (на странице  configure clouds)
Jenkins URL http://jenkins:8080
Jenkins tunnel jenkins-agent:50000
Пробовал сменить порт 50000->50001,но по прежнему не работает(
Подскажите пожалуйста  куда смотреть или что править в данном случае?

зачес sh 'exit 1'  так ошибки не увидем
catch(e) {
   // делай что хотел для стейджа при ошибке
   throw e
}