Issue
-
I need to pin a specific version of a CAP plugin that is not the latest, so I disable the automatic upgrade of plugins and manually install the version of the plugin that I want to use. The report in the plugin manager site shows that the installation was successful. However, the change does not survive a restart.
Context
The CloudBees Plugin Installation Manager ensures that all CAP plugins installed in a controller or operations center meet their dependencies at the startup of the jenkins process. Among other things, this means that it will request the upgrade of any plugin that is in a lower version than required by a CAP plugin that is installed in the instance, regardless what’s your BeeKeeper configuration for automatic upgrades at startup. In such cases, you will see the following trace in the startup logs:
INFO c.c.j.c.i.CJPPluginManager$URLInstaller#install: Requested [UPGRADE] of plugin [cloudbees-bitbucket-branch-source] to version [887.va_d359b_3d2d8d] completed INFO c.c.j.c.i.CJPPluginManager$URLInstaller#install: Requested [UPGRADE] of plugin [blueocean-bitbucket-pipeline] to version [1.27.13] completed
Troubleshooting
To identify what plugins are behind the request by the Installation Manager to upgrade your plugin, you need to identify this plugin’s dependants. For that, you can run the following script on the Groovy console of your affected managed controller/client controller: pluginDependenciesReport.groovy.
Please note that you will need to define the variable pluginShortName and assign it the ID of your plugin. The report will not only show the dependant plugins but also all dependencies, direct and indirect of the plugin. The script will only work for plugins that are installed in the instance.
Once you have the list of dependants, use our CloudBees CI plugins site to go through each of them and find which ones require the newer version of your plugin.
Resolution
-
If the dependent plugins are not in use, we recommend that you remove them from the managed controller/client controller. Having unused plugins in the instance adds complexity to the plugin dependency model and potential sources of vulnerabilities.
-
Disable CAP (not recommended in general).
Workaround
Once you have identified the dependent plugins causing the unexpected upgrade, you can consider downgrading them to a version that does not require a newer version of your plugin than the one you are trying to pin. Kindly note that you might need to repeat the same process for these new plugins, as other dependants may arise that require higher versions of them.