I run an offline Jenkins server with a set of plugins that I fetch and build on the internet ahead of time using nixos and the jenkinsPlugins2nix tool. Mostly this works pretty well, but because of how jenkinsPlugins2nix currently works I have to manually set plugin versions quite a bit, which is pretty tedious.
I see that the update-center.json file gives a list of plugins, and that the documentation here advertises that they are designed to be compatible with specific Jenkins versions. I think updating the jenkinsPlugins2nix tool to use this file could make the system work much better. What I wasn’t able to understand was if all the plugin versions supplied in update-center.json were designed to not only be compatible with the given Jenkins version, but to also be compatible with one another.
For example if I install plugin A which depends on B, can I reasonably expect that the version of plugin B at the “top” level of update-center.json will be compatible for plugin A? I’ve found several examples where the version of B specified in A is something like 1.3, and the top level version is 1.5 (so same major, equal or higher minor version) but I didn’t seem to come across any where the top level version did not satisfy the dependency version. Are there more complicated scenarios I need to watch out for, like situations where plugins A and B come from update-center.json and they both depend on C, but the version of C in update-center.json does not mutually satisfy A and B?
I guess my question boils down to, can I follow the dependency tree in update-center.json, and install versions based on the root.plugins.<plugin name>.version version and have a consistent set of plugins, or is there some higher order dependency resolution that needs to run against update-center.json?