job-dsl-plugin VS jenkins-script-console-scripts

In declarative syntax, it uses the various DSL plugins to parse and interpret the file.

I've used to stuck with the Dynamic DSL as it does not natively support unit test so I have to replace all Dynamic DSL with the configure block, ugly but work!

Job DSL is a tool, but I still do not see how I would use it intelligently for this system. The REAL WORLD EXAMPLES are laughable at best, and I see nothing that shows me a way to use perforce triggers on 50+ different streams to kick of specific builds. (If there is an example in the docs somewhere, please point me to it)

You can capture plugins and Jenkins versions using the script console to provision a second pristine Jenkins for additional testing like upgrade testing. I go deeper into this with complete immutable Jenkins infrastructure with jenkins-bootstrap-shared.

Groovy scripts for Jenkins administration

Based on other comments I recommend: - Committing your Jenkins config to a local git repo so you can see how an upgrade affects it with git diff - Capture you plugin versions with Jenkins version

You can do this by script console yourself and use the community docker image. Alternately, you can try out jenkins-bootstrap-shared project I made which pulls Jenkins into a JKD8 container (I plan to upgrade it to OpenJKD11 since Jenkins now supports that).

Delete builds for branches and tags after 120 days

If you're an admin in Jenkins, then you cam retrieve the credentials via script console. I did a talk which discusses using the script console. You can run this script which exports most common credentials in Jenkins. It will render them as plain text which you may be able to use to log into vault.

Here’s a list of properties I’ve found. https://github.com/samrocketman/jenkins-script-console-scripts/blob/main/aggressive-cloud-provisioning.groovy