[cmehdy]

It's still a miserable experience to maintain it, update it, deal with mostly old plugins, dynamically loading the tooling, groovy idiosyncrasies.. and UI/UX that despite recent efforts continues to feel terrible.

Managing the underlying infra is painful, and it remains a security liability even when not making obvious mistakes like exposing it to any open network.

And good luck if you're having that fun at a windows shop and aren't using a managed instance (or 5).

[linsomniac]

>It's still a miserable experience to maintain it...

How so? I've been maintaining an instance for a decade, and it really doesn't seem that bad. Updating plugins we do about monthly, it's largely clicking a couple buttons in the UI. Updating Jenkins itself is an apt update. Groovy takes a bit to grok, sure, LLMs help a lot here. The UX isn't that bad, IMHO, but I can see why some would say that. We've switched over almost entirely to using a couple runners, docker, and Jenkinsfiles, which works great. We do still run deploys directly on the Jenkins box, largely because we need to run them single-threaded so they don't step on each-other with load balancer rotations.

[cmehdy]

Your use case is just fine because you're barely actually using Jenkins.

I can give you a few examples of where it falls short:

- security: there are constant CVEs about anything and everything in Jenkins

- upgrade paths: if your company uses lots of plugins, the resulting spaghetti is of Italian proportions

- if said company is in a Windows-only infra, on prem, and they still decided to use Jenkins then good luck doing anything. Try putting an agent on a non-system disk for example, Windows paths aren't handled and you find yourself already passing very specific "pre" commands that your master will send over ssh.

- Said ssh connection can be lost due to a variety of things for which there are quite a few combinations of parameters when invoking Jenkins

- While we're at it, SSO isn't exactly supported in Windows environments. There are two external plugins you can try, one created because the other doesn't work, and even then good luck with that.

- At scale you end up having to be at least minimally interested in GC tuning, as Jenkins runs within the JVM

- UI: normal "Views" are not informative, and a bunch of custom views need to be made but rarely work with all sorts of plugins that people using your CI can consider crucial (say, parametrized cronjobs)

- Using the functionnalities Jenkins offers to "install tooling". Try to get it to use a certain version of node in a pipeline. Any current typical CI solution turns that into a straightforward task that's extendable, but in Jenkins you have to configure a very archaic and barely-working "tooling" area in your system to use that, and this barely works beyond the most basic tools.

- Having to maintain enterprise-level groovy libraries. Good luck. It's Groovy but not exactly Groovy. It's all inside the JVM, but inside Jenkins's abstractions of it inside of the JVM.

- Good luck monitoring lots of agents and doing typical tasks with them. Maintenance Windows are slowly coming in, monitoring sort-of-kinda-works via plugins..

I've maintainted instances in small companies and larger ones. With less custom stuff and with a lot more. Compiling C++, C#, Java/Kotlin, Objective-C/Swift. Building webapps, iOS SDKs, Android SDKs, and native Windows apps.

Jenkins can do everything if you bend it the way you want with some plugins and custom code. That's a strength that nothing else offers, but by and large it is a weakness of CI in the long run. Being opinionated isn't amazing, but sometimes it is required to be less complex, easier to maintain, more secure, easier to use, etc.