Suggestion to upgrade from 2.332.3 to latest LTS version(2.440.1)

We want to upgrade a Jenkins instance from 2.332.2 (from May 2022) to 2.440.1 (2024). Because this is such a large jump of LTS versions - we were planning to do a rolling upgrade by upgrading to every other LTS version until we reach 2.440.1 .

Is there a strategy recommended for this type of upgrade? Not sure if this is the right approach. Thanks in advance.

It all depends how complex are your jobs and the plugins that you use.
The biggest change is the required java version. You need at least java 11, but better to directly go to java 17.

Take look at

Another approach might be to do a single jump as I described here:

Anyway make sure you take backups, ideally you first try with a test instance and check if everything works.


snapshots are huge… read everything and try to account for changes. Hope my guide (linked above helps). I always consider myself a student of work; but feel free to drop questions here.

1 Like

Hi @mawinter69, Thanks for your suggestion, do you know how we can get list of all used and unused plugins from jenkins, there is one plugins called plugin-usages-plugin: Plugin Usage but its not compatible with our jenkins version i.e. 2.332.3 as its requires jenkins version 2.361.4 and higher to use, could you please suggest on how we can get list of all used and unused plugins?

You can install version 3.0 of the plugin that should be compatible with your Jenkins (you can get that version from here:
But it will not be able to find all plugin usages.

Thanks @mawinter69,yes you are right, I faced same issue now, do we have any script which gives us used and unused plugin, I tried to find but no luck

there is a gui command < http://<jenkins-url>/script> you can run to list all plug ins… I used it a number of month ago now. But it’s not super useful:

  plugin -> 
    println ("${plugin.getDisplayName()} | ${plugin.getShortName()} | ${plugin.getVersion()}")

output is a matrix of “Display name | Shortname | version”

StackOverflow source

Many plugins are pipeline only and just provide steps. And if they are used in Jenkinsfile you have no chance just look in the jobs config.
You would need to scan also the workflow xml files of builds (there are the descriptor ids written), but that is quite time consuming and you need a mapping from descriptor ID to plugin.

I would go to plugin manager and look at the installed plugins. Start with those plugins that can be uninstalled. For each you need to look what it is doing and think if it might be used.

There are some type of plugins where you might have several installed but only one of them is used at a time. E.g. the security realm plugins. I’ve seen many instances where ldap, pam, AD plugins are installed. You need only one of them.
Similar for authorization with Matrix Auth and Role-strategy

In the end you have the potential to remove maybe a few plugins.

What one might consider is removing all the blue ocean plugins (Blue ocean is not actively developed anymore) and stage view plugin and replace it with Pipeline Graph View

Hi @mwp565733,
I refer same document for listing out all installed plugins but here what I want is to get all plugins which are in used, as installed plugins list is hug hence its time consuming to go through each & every plugin to check whether it is in used or not

Sorry @snehalhingane I was OoO for a few days on holiday:

As for usage, I definitively suggest the Plugin-usage-plugin linked above by MAWinter69. It’s better than nothing, I found it useful while ‘tending the weeds’ in the plugin garden. You can also try to deactivate plugins that are not being used. If there are dependencies it will let you know in the UI that “This plug is is required for plugin ABC” and you will not be allowed to deactivate it.

That being said: I build up a script that you can run from the server to query mission critical plug-ins. this will run thru all executed jobs and extract which plug in were used and what version: this is a bash shell that you run in $(JENKINS_HOME)/jobs

# runs thru all jobs that have been executed, looking for config.xml files and outputs strings with plugins= to jobs_with_plugins.txt
grep -lR --include=config.xml "plugin=" > jobs_with_plugins.txt

#visit each job that used a plugin collate all plugin references in to one file
while read p; do
tmp=$(cat "${p}" | grep "plugin=")
echo ${tmp#*plugin=\"} >> usedPlugins.txt
done <jobs_with_plugins.txt

# clean up out put
sed -i -e 's/> </\n/g' usedPlugins.txt

while read q; do
echo ${tmp1%%\"*} >> usedPlugins1.txt
done <usedPlugins.txt

# remove working files, uncomment below if interested
rm jobs_with_plugins.txt
rm usedPlugins.txt
mv usedPlugins1.txt usedPlugins.txt

# display deduped list, though usedPlugins.txt remains duplicated.
sort usedPlugins.txt | uniq > usedPlugins.txt

Hope that this helps.

1 Like

Hi @mwp565733, Thanks for sharing
is this script is working?
I’m getting syntax issue

looks as if you have windows line breaks in the file
try to run dos2unix to convert them to unix line breaks

I do have this running and tested in my RHEL 8.9 box.

Run Markus’ suggestions . I assume you copied from the blog post, there could be invisible characters that are giving you issues. I typed it all in without issues before

After creating the shell script.
From command line,
will clean up those characters

Then run it ./

Sorry I was having issues dropping in the snippet properly, probably captured the character

Thanks @mwp565733, I’m able to run the script now but can see blank usedPlugins.txt file


  1. your jobs folder isn’t populated, aside from subfolders
  2. your jobs don’t use plugins in the config.xml file

More probable

  1. something was introduced as a bug

Comment out the rm and mv lines and look at the resultant files.

Jobs_with_plugins.txt lists all jobs that have plugins mentioned
UsedPlugins.txt is initially a non-clean list of plugins
UsedPlugins1.txt is cleaned up (currently blank).

I’d also try keying in my script directly in to unix, instead of copy paste.