круто что до таких масштабов смогли доехать без мониторинга  и тюнинга))

С языка снял)

Да там вообще непонятно зачем столько ресурсов на мастере. У меня дженкинс в более скромной конфигурации и тащит побольше без явных проблем. Единственная разница - на каждом слейве больше слотов

там же миллион причин - от безумных плагинов (дада, привет diskusage),  несконфигурированных плагинов , хранения истории билдов/конфигов годами, мавен со своими фингерпринтами, или какой-нибудь спиннакер который пойдет и запросит всю историю всех веток всех проектов . заливать всё ресурсами конечно можно - но результат очевиден

Ребят, привет.
Есть потребность запускать джобу, через некотрое настраиваемое время после другой джобы.
Нагуглил trigger upstream, но вот пока не могу найти ничего про отсроченный запуск.
Делать sleep в самой джобе не хочется, потому что она будет занимать раннер

Привет. А смысл в задержке?

Скажем так. То с чем должна поработать эта джоба, может быть удалено в связи с человеческим фактором.
Не верно вбили параметры и тп. По этому вторая джоба и должна подождать некий период времени.

А в вторую сделать зависимой от первой никак?

Кмк самый простой варик - сделай пайплайн, код которого не крутится на ноде, да будет висеть джоба на мастере и ждать, но сборщики будут свободны

Ну только если опять же через sleep какой нибудь?

А можно по подробнее про это? Ключевые слова, я нагуглю дальше)

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

да все просто - pipeline, groovy, код груви для ожидания должен вызываться вне блока node

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

Ну задача сделедующая.
Разрабы пишут код, коммитят в релизную ветку.
В определенный момент происходит отрезание новой версии с релизной.
Вот тут может быть много моментов где можно ошибиться. Верно выставить тип версии мажор/минор/патч.
src ветку и тп. Там много нюансов почему это не сделать через гит. Ну т.е. давайте это просто воспринимать как неизменное условие.
И вот далее, после того как версия отрезана, надо вытащить с нее все таски и пройтись по джире, выставляя fixVersions в которую они вошли. И тут мы подходим к проблеме.
Казалось бы, это можно сделать сразу, но мы в реальной жизни где нично не идеально.

Если по какой-то причине версию создали не верно. Минор перепутали с патчем, ветку релизную перепутали или вовсе собрали нето, то версия будет удалена. Но если fixVersion проставить сразу, то потом нужно будет долго и кропотливо это все дело откатывать и в джире. Решение в лоб, делать некий delay между срезом версии и простановкой fixVersion в jira.

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

но это не защищает от того что в ней будет ошибка.

Ну так задержка тоже не защитит тогда

задержка поможет тем что будет время уже после создания. Как раз то время когда начинается у манагеров «ой-ай, не то, не туда, давайте откатим перевыкатим»

Делайте срез гитом по номеру фиксвершн