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

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

Jenkins.instance.getAllItems(Job)
// filter jobs by name if needed
.findAll { it.fullName.startsWith('sandbox/tmp-magic') }
.each {
  it
  .getProperty(ParametersDefinitionProperty)
  .getParameterDefinition('MAGIC_PARAMETER')
  // `each` ensures nothing happens if `get` returns null
  .each {
    it.defaultValue = 'shmagic'
  }
  // the job has changed, but next config reload (f.x. at restart) will overwrite our changes
  // so we need to save job config to its config.xml file
  it.save()
}

но там нужно будет прям хорошо курнуть, как именно в жене нужные потроха подвешены
...ну и надеяться, что со следующим апдейтом оно не сломается из-за какого-нибудь переименования в стиле ParametersDefinitionProperty -> JobParametersProperty, или чего похуже

а какая исходная задача решается этой подменой крона?

это звучит не просто странно - дико.
если надо описать джобу в коде, описывать надо целиком
так, что либо переписывай джобы на job-dsl/jjb, либо чини jenkins-cli (я не знаю, почему оно не работает, не пользуюсь)

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

jenkins-cli выпилен начиная с версий 080
точнее не весь, а функционал с remoting

Здравствуйте, есть такое дело: есть несколько стейджов в пайпе. Иногда они могут падать и тогда такой стейдж становится FAILURE а сама джоба UNSTABLE. С другими тоже может быть такая ситуация. Можно ли сделать так, что бы если таких стейджов будет больше чем 3 - джоба тоже была FAILURE, а не UNSTABLE. Какой то счетчик или что-то типа того. Может есть у кого нибудь такой пример

точнее не весь, а функционал с remoting

перефразирую: это задача, а не проблема с которой боретесь :)

для чего такая магия в принципе нужна?

1. Есть сборки, которые должны выполняться по расписанию на 4 недели, причем не каждый день и не в одно и то же время.
2. Есть сборки, которые выполняются по таскам Jira, в которых содержится информация, что и как собирать

и все это работало в версии 076 до апгрейда на 222 ... дальше апгрейдить нельзя, так выпилены workflow dsl, которых у нас много, и без конвертера на пайплпйны переходить нереально трудоемко

использовался для этого внешний groovy скрипт,  который запускался через jenkins-cli
 def  spec = args[1] + " " + args[2] + " * * *"
 hudson.triggers.TimerTrigger newCron = new hudson.triggers.TimerTrigger(spec)
 newCron.start(job, true)
 job.addTrigger(newCron)
 job.save()

Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте

а почему психопат на свободе разгуливает?)

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

не все так просто ... перед тем, как поставить на крон джоб по таску, надо проверить, какие джобы когда будут выполняться по крону и какие джобы уже выполняются, чтобы избежать конфликтов по апдейту SVN и по содержимому воркспейсов ... этот функционал (получения списка джобов) тоже remoting и тоже deprecated

запускать джобы сразу после проверки нельзя, так как по регламенту надо оповестить всех заинтересованных участников процесса (их больше 150 в 3х независимых организациях) за 15 минут до того, причем за эти 15 минут могут поступить заявки на отсрочку или отмену запуска сборки

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

Привет! Существует ли возможность в Jenkins создать агента снаружи Jenkins? Имею ввиду, не создавая новую ноду в админке.

если надо извне пинать jenkins или получать от него информацию, то это можно сделать шелловским скриптом через curl или jenkins-cli (в ограниченном объеме) ...  также можно из jenkins вызвать скрипты gj ssh