Есть джобы А, Б, В
Джоба А имеет промоушин шаг, который тригерит Б, Б отправляет запрос с уникальным ид на удаленный сервак. Через какое-то время (неопределенное, может быть час, а может и неделю) удаленный серв пошлет обратный запрос на дженкинс с этим ид чтобы тригернуть джобу В.
Хочу: Чтобы промоушин шаг у А получил успешную отметку только после того, как полностью выполнится джоба В. При этом если в промежутке будет выполнена другая цепочка этих джоб, то она не должна повлиять на статус предыдущей.
Единственный способ который я знаю - Parameterized Trigger , в котором в месте триггера другой джобы стоит “Block until the triggered projects finish their builds”, единственный момент - первая джоба будет “висеть” все это время (хотя я не представляю другого сценария, если вам реально нужен статус именно той другой джобы). В ней кстати можно и поведение настроить, по дэфолту Success - Success / Fail/Unstable - Fail.
В случае, когда мы не можем предсказать время ожидания ответа, нет смысла держать джобу в висячем состоянии, ибо во-первых, она будет подъедать ресурсы, что в итоге может привести к утечкам, падению пифоменса и прочей ереси. Во-вторых, при определенных обстоятельствах можно вообще лишится возможности ее остановить без ручного убиения процесса.
Навскидку, можно вручную (скриптом) редактировать статус билда (build.xml) джобы А по требованию. Для того, чтобы изменения вступили в силу, нужно либо вручную вызывать reload from disk, либо через jenkins-cli.
Другой вариант - заменить в джобе А промоушен на обычный триггер (по сути превратив ее в некое промежуточное звено). При этом, промоушен делать некой джобе Г из В. Если нужны еще какие-то доп. результаты из предыдущих джобов, можно попробовать подключить text-finder plugin.
В общем, из описания не совсем ясна приоритетность имеющихся джобов. В частности, что происходит дальше с А, что ей обязательно нужно изменить статус аж после выполнения В.
В таком случае изначальная задача стоит неправильно. Билд в любом случае будет иметь какой-то статус - fail, success, aborted. То есть первая джоба, в случае не ожидания ее, не будет иметь правильный статус, т.к. если вы ее остановите или закончите success-ом, то она уже получит какой-то совершенно не относящийся к B статус.
Кстати ждать все даунстримы в первой джобе - это основной workflow работы с gerrit (иначе ты получешь неправильный фибэк в систему, который основывается на статусе самого первого триггера). Там может и по 40 минут и по несколько часов висеть - смотря что и как вы тестируете и собираете.
Ну, несколько часов - это одно дело, тут проблем нет. А вот когда по условию надо ждать неделю, то тут слишком много подводных камней появляется. Банальные проблемы сети, даунтаймы с проф. работами и т.п. приведут к потере результатов в лучшем случае. А если из-за бага ответ вообще не придет или затеряется? Джоба В не тригернется, а А будет висеть вечно, пока не съест всю память. По-моему, нужно более детально разобрать сам флоу. Возможно структурно можно все сделать гораздо проще. Но на абстрактном примере сложно что-либо обсуждать.
Я не спорю
Я веду к тому что изначально поставленная задача в этом случае имеет неверную формулировку. Представь - у тебя есть A который стартует и не ждет другой билд. Если он заканчивается, у него в любом случае появится какой-то статус. Если же этот статус чем-то важен, и даже если он поменяется в будущем, то какая-то часть системы будет некоторое время опираться на неправильный статус, который не был обусловлен значением билда B, а только статусом A до того как B каким-то способом поменял ему статус (надеюсь понятно выразился).
Статус самой джобы неправильным не будет. Она завершилась и будет пасс или фейл. А статус промоушина должен зависеть от джобы В. Так делается, потому что в этой цепочке есть ручной процесс зависящий от людей вне юрисдикции компании.
А делает что-то, Б отправляет это совсем в другую компанию, к инфраструктуре которой я доступ не имею. Компания что-то там ваяет и присылает пакет софта мне (через час или неделю). Посылку софта обратно можно перехватить проверив обновления архивов, это делает джоба В. И вот когда В найдет обновления, она копирует себе бинарники из архива и ставит промоушин для А, типа всё, запромоутилось. Если архив не обновляется никогда для джобы, то и промоушина у неё не случится.
testomat.io управление авто тестами