Bundled plugins: how are they used in 2020

[Lee Meador]

I'm trying to figure out today's role for bundled plugins. Google is not as friendly as usual in finding information for me on this subject. I have found some things that are very confusing taken together.

There is a tool for creating Jenkins war files with plugins bundled. It has a new version 2 that seems to imply there is still a purpose for bundling plugins.

There is code in the Jenkins plugin manager cli tool that takes the versions of bundled plugins into account when deciding which version of the plugin is best to get. On the other hand, it won't download a plugin from the update center if its present bundled in the war.

There is a maven plugin that has some secret purpose I cannot find described on the plugin pages.

There is a page on the wiki with a big disclaimer that plugins are not pinned as of Jenkins 2. But it doesn't say whether the bundled plugins still do anything or not.

A long time ago, maybe all the way back to Hudson days, plugins were bundled in the Jenkins war. Whenever Jenkins restarted, it would reload the bundled plugins to the plugins folder off $JENKINS_HOME except for any such plugins that had a corresponding pinned plugin in the plugins folder. The pinned version would be preserved and not reloaded from the war.

Also from back in the day, I found an old email from Jesse Glick explaining a tiny bit about the version that first got the plugin UI and the version that first started pinning plugins. None of that seems relevant today, but I can't find any modern info.

Release wars from the Jenkins OSS project don't seem to have bundles plugins. Release wars from Cloudbees do. 

Please do not feel I am asking for 10-12 years of history in a response. I'd be glad to have some links explaining how it works in 2020. Or perhaps just some clues that I could pass on to Google for searching out this stuff.

Thank you

-- Lee Meador
Sent from gmail. My real email address is lee AT leemeador.com

[Jesse Glick]

On Thu, Jan 2, 2020 at 5:46 PM Lee Meador <l...@leemeador.com> wrote:
> Release wars from the Jenkins OSS project don't seem to have bundles plugins. Release wars from Cloudbees do.

Yes, CloudBees products use bundled plugins; OSS Jenkins releases do
not (as of 2.x).

The WAR packager tool can add bundled plugins, which is mainly handy
for running integration tests without needing to bother with
installing plugins at the start of a test.

For the most part you can ignore the plugin bundling system, I think.
(It is unclear from your message how you got onto the subject.)

[Ted Xiao]

I use hpi:custom-war in CI/CD flow https://jenkinsci.github.io/maven-hpi-plugin/custom-war-mojo.html

so I can control all the plugin dependencies in one place

[Lee Meador]

Jesse

I've been doing some work on the plugin installation manager cli tool. Right now, I'm trying to figure out whether the code in it that deals with bundled plugins is doing what it should. The requirement for that project said to just do what the install plugins script from the Docker distribution does. 

What the script does is to care about the version of the bundled plugin if it would be needed by the dependencies listed in some requested plugin. Bundled plugins are treated identical to an installed plugin while figuring out dependency plugins and their versions. So if a dependency plugin has a min required version greater than the bundled (or installed) plugin, it will replaced with the greater min version when the script runs. In essence, bundled plugins are treated just like installed plugins in this way. That suggests to me that whoever wrote the script expected bundled plugins to be installed on startup unless a higher version was already installed. I don't know if that is true any more.

Then there is the fact that I don't know my way around the Jenkins code. 

I suspect that the Jenkins UI for managing plugins has rules to decide which versions to offer and such. I have no idea how to find that code. I have no knowledge about whether or not it takes bundled plugins into account. Maybe it doesn't when offering but does when loading dependency plugins.

Similarly, there is some code that lets you select and install plugins on first-time startup. It offers to install "suggested" plugins or it offers a list of plugins and installs versions it selects. Since I typically install the Cloudbees' version and it's been a while since I installed an OSS version, I don't know if that is a part of Jenkins OSS or not. If it's in OSS, I don't know where the code is. If only Cloudbees, I don't know how that feature would interact with what the  plugin installation manager cli tool is trying to do. And I don't know how the Jenkins OSS group interacts with Cloudbees in regard to this sort of thing. I don't actually know if I need to know that.

Does that give you some idea about what kind of info I'm looking for? If I only get one question answered, I would like to know whether Jenkins still installs the bundled plugins on startup forcing a return to "official" versions every time.

-- Lee

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0qqbRRVUch30uyBwhM4T6Sehtbq9q2dVWW1yTUMCkLaw%40mail.gmail.com.

--

[Lee Meador]

Thanks Ted,

When you bundle plugins, what does it cause to happen when Jenkins runs? What is different?

-- Lee

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/2b0b45ef-c2ab-404b-a0ca-c600001a79c0%40googlegroups.com.

--

[Jesse Glick]

On Fri, Jan 3, 2020 at 12:46 PM Lee Meador <l...@leemeador.com> wrote:
> whoever wrote the script expected bundled plugins to be installed on startup unless a higher version was already installed. I don't know if that is true any more.

Yes, that sounds right.

> Then there is the fact that I don't know my way around the Jenkins code.

Plugin management code is rather complicated I am afraid, and
undocumented. If you have to dig into sources, start with
`PluginManager`.

> there is some code that lets you select and install plugins on first-time startup. It offers to install "suggested" plugins or it offers a list of plugins and installs versions it selects.

Yes, in the setup wizard. For OSS Jenkins this does nothing different
than just going to `/pluginManager/available`, selecting the same
plugins, and installing them without restart.

When the WAR includes bundled plugins, these get installed immediately
upon startup, before the setup wizard is even displayed. I think
CloudBees products actually use a custom proprietary component
(`cloudbees-installation-manager`) to do this, rather than the bundled
plugin system built into Jenkins core, but I do not know much about
the topic.

> I would like to know whether Jenkins still installs the bundled plugins on startup forcing a return to "official" versions every time.

It should only install bundled plugins during startup if they are not
yet installed, or are installed but in older versions.

I am not sure who defined the requirements for the project but I would
suggest just ignoring bundled plugins unless you have a specific
reason to deal with them and are ready to test various such scenarios.