Всем привет, кто работал с generic webhook trigger. Есть такой вопрос, можно ли на вебхук возвращать модифицированный json в ответе в рамках одной сессии

Грубо говоря сессия будет открыта, выполняется логика в Jenkins job по вебхуку и вернётся модифицированный json с данными, как при работе restapi

Почему не nginx с условным Let's Encrypt?

Там ведь тоже указывается репа и ветка в настройках 🤔

Так это же и правда циклом просто делается

node {
    def stage1 = {
        stage('stage1') {
            println 'stage1'
        }
    }
    def stage2 = {
        stage('stage2') {
            error 'error stage 2'
        }
    }
    def stage3 = {
        stage('stage3') {
            println 'stage3'
        }
    }

    for (i = 0; i < 3; i++) {
        stage1()
        try {
          stage2()
        } catch(e) { continue }
        break
    }
    if (i == 3) { error 'error all attempts' }

    stage3()
}

Правда у тебя в интерфейсе будет дичь в зависимости от количества попыток
https://i.ibb.co/kxvd17y/image.png

Спасибо, попробую. На интерфейс, в этом случае, всё равно. Ситуация когда надо вернуться очень редкая

ну там вместо try catch просто реализовать логику после stage2() по которой надо понять что необходимо вернуться, и в этом случае делать continue в цикле. Бесконечного цикла легко избежать, надо просто сделать конечное количетсво итераций =)

ок, спасибо ещё раз 😊

Ну хз. У меня точно такие-же истории. Всякие кривые тулзы для сборки могут с первого раза не сработать. Вот и приходится делать воркэранунды.
Как тут дизайн джобы не делай, у тебя будет сборка либо регулярно падать, так как это не от пайплайна зависит, а от кривых процессов сборки. Либо ты накостылишь с количесвтом попыток, и тебя не будут беспокоить, либо каждый раз будут писать что сборка упала

У меня ситуация с тем, что надо прогонять тесты используя удаленные виртуалки, профилей мавена 4, а виртуалок 3, поэтому я реализовал параллельные потоки,  флаг что виртуалка занята и 4-й поток ждет пока освободится какая-нибудь из 3-х.  Но бывает так (я не могу пока отловить причину, всё очень быстро происходит 😊 ) что два потока занимают виртуалку и я проверяю перед запуском тестов, а тот ли поток запускает этот набор тестов. Если нет, то надо вернутся на предыдущую стадию поиска свободной виртуалки. Приложения уже собраны, конфиги готовы, надо просто заново залить на виртуалку и прогнать тесты.

а как у тебя "поток заходит на виртуалку", через node(){...} ? если так, то не проще ли на тех нодах сделать просто по одному экзекутору?

По ssh. Как  экзекуторы нельзя подключить, не рулю главным дженкинсом

а не дешевле завести 4-ю виртуалку? )

не дают, жадины 😊

вторую и третью еле выпросили

https://plugins.jenkins.io/throttle-concurrents/
вот этот плагин может быть поможет? )

запускаешь 3 параллельных теста на каждой из ВМ, 4я ждет очереди просто и займёт первую освободившуюся

Я так понял это плагин для одного пайплайна, А у меня их 4, там отличаются профили мавена для сборки приложения и наборы кукумбер тестов,
Но, в любом случае, спасибо, почитаю подробнее, может придумаю как прикрутить

ребят, а с чем может быть связана ошибка:

java.io.IOException: Not enough storage is available to process this command
  at sun.nio.ch.FileDispatcherImpl.read0(Native Method)

на физическом диске 300 гигов свободно.

а оно не на венде в 32битной джаве запущено? )