The Dependency and Plugin Hell That is Jenkins

Jenkins’ plugin model has become the “Slippers cat and duck” story of CI/CD. It’s not good - as you'd imagine when someone feels the need to coin your model "dependency hell."

Have you seen the video of Slippers the cat yet? You know, the one where Slippers brings an entire, live duck into his house and his owners chastise him with, “Slippers, you stupid cat! What have you done?!” If you haven’t, you should watch it right now then come back. Go on, I’ll wait. 

Now tell me it’s not super applicable to Jenkins: Jenkins, you stupid tool! How did you get over 1,700 plugins through the cat flap?!

I’ll drop the Slippers analogy for now, but honestly, does it not make you sweat a little bit to look at the Jenkins plugin index? With 1,788 plugins currently available, it’s a smidge overwhelming to peruse the list. Sure, it’s great to have a ton of choices, but with so many plugins, chances are high that many are defunct and/or abandoned. 

Worse yet, almost all of these plugins have dependencies on other plugins, which create chains of dependencies - and that’s the biggest problem with the Jenkins plugin model. Jenkins’ dependency hell is enough to make you rethink your whole CI/CD strategy, and I wouldn’t blame you one bit - because, to me, it sounds like a whole lot of nope.

Let’s Talk About Plugins

Let me get this out of the way right now: no, not all plugins are bad. There are some amazing plugins on the Jenkins plugin ‘store’ that are super useful and will, in the long run, save you tons of man hours. Plus, plugins usually provide loads of extensibility. But when you look at that list of 1,788 plugins, how many of them are actually usable, well-maintained, free of dependencies, and free of security vulnerabilities? 

How many will you need to go through before you find one that does exactly what you need it to? How many other plugins will you need to install and maintain besides the one you want, due to dependency chains? What happens when there is a conflict between all these dependencies?

Lastly, what if the plugin creator decides to stop maintaining it - are you able to take on the task, or will you need to find a replacement that (hopefully) does what the old one did?

Welcome to Dependency Hell! Population: You.

Little known fact: the seventh circle of hell is also known as Jenkins Dependency Hell. 

Dependencies are exactly what they sound like: you install/upgrade one plugin, and now have to install/upgrade 5-6 other plugins to make sure the first plugin works - and oftentimes, those plugins will be for stuff you don’t even use; they’re simply needed by your original plugin. 

The best/worst dependency example I could find is Blue Ocean - look at that dependency list. And that’s just for a pretty UI! Not hard to believe, but they’ve been called out before on the absurd amount of dependencies required. 

It Gets Worse...

When it comes to dependencies, things can get very convoluted, very quickly. The more plugins you have, the more likely there is to be an issue when you update - and one of these issues is version dependencies.

Let’s say you have Plugin A and Plugin B installed. Plugin A’s current version is 2.4, but to be compatible with Plugin B, you have to use version 1.8. In theory, that’s not a huge problem - but in practice, what if version 1.8 of Plugin A isn’t compatible with Plugin C, a new plugin you’re looking to install? In short: this breaks the job. 

Situations like this make it so you can’t enable auto-update on your plugins. In these cases, you now have the mental labor of keeping track of which plugins need to stay at their current version and which you can update. And since most people don’t want to waste energy on this, they’ll simply stop updating plugins at all, which now introduces the risk of vulnerabilities. 

And Worse...

If that wasn’t enough, here’s another situation users will sometimes run into: a plugin may have a report for a vulnerability in one of its versions, but the plugin that depends on it hasn’t yet been updated. Your choices then are to either accept the security risk, or cut ties with the plugin - and that could cause downstream impact. To add another layer of complexity, certain plugins are only compatible with certain versions of Jenkins, too. 

Lastly, there’s the issue of backwards compatibility. A user shared his experience with library dependencies: “[...] simply including these common dependencies in Jenkins itself leads to problems such as never being able to upgrade that library again if it breaks backward compatibility in the slightest.” This is an issue that can easily be overlooked until something breaks - and looking at the user’s four proposed solutions, none of them look easy or intuitive in any way, shape, or form.

As We Like to Say: Fire Your Butler. 

Jenkins, a few years ago, did things no other CI/CD platform could. It had its day in the sun. But now, it’s such a pain to manage and maintain - with plugins, dependencies, and especially when it comes to the need for hundreds of scripts - that it just isn’t worth it anymore. Especially when there are some perfectly good platforms out there, with all that extensibility built in natively. 

For instance, we can toot our own horn and proclaim loudly and proudly that Harness has only 150 plugins - and no dependencies! You read that right, NO DEPENDENCIES between plugins! Every plugin is executed as a self-contained Docker container where the latest version is always the one that runs. You never download plugins or maintain them in any way - unless you want to contribute to the open-source. Why not get a free trial of the CI/CD platform that makes life easier? Don’t be the Slippers of your organization: say no to dependency and plugin hell.