Having a good set of plugins that integrate well should limit the complexity explosion and the number of edge cases users run into. So that's an improvement. It won't fix the Jenkins Heisenbugs though, of course :)
Does anyone have Jenkins in production and found it to be reliable and pleasant to use?
I had to do lots of Jenkins integrations some time ago, and even though I tried to minimize the number of plugins and make things as simple as possible, things would randomly break from time to time or exhibit weird behaviour etc.
I had the impression that Jenkins is deeply conceptually confused about some of its concepts, e.g. how builds are triggered. Also, it is a huge pile of untestable spaghetti code which explains the weird bugs.
I modified an open-source plugin only to find out that it's almost impossible to write meaningful tests for it: you can't even mock Jenkins API without using the darkest Java mock magic. Jenkins classes are just written in an old style that makes testing _really_ hard but probably can't be changed without breaking all of Jenkins.
I tried Jenkinsfile which was only even more unreliable (at the time at least, this was > 1y ago). The whole idea of using groovy, modifying the hell out of it to make it even more weird and surprising and edge-casy just didn't go well for me.
I ended up with generating a _lot_ of very simple jobs for each project and connecting them via triggers instead. It was not very pretty, but it was the most reliable that I could get out of Jenkins.
So the thought of integrating Jenkins deeply into you deployments, talking to Kubernetes and sitting in the middle of a huge pile of complexity (Jenkinsfile, Dockerfile, Helm, ...) and magic "that you don't need to worry about" scares the hell out of me.
But then again, if you want to do CI/CD with Jenkins that's what you might want, right?
(I would prefer more simple approaches if forced to use Jenkins, though)
> The machine that creates paper clips will not kill off anyone who tries to turn it off because it does not have self-preservation
The idea here is that the algorithm tries to maximize its paperclip production and turning the machine off will definitely have a negative impact on its paperclip production. So the machine will take the most efficient measure to stop that negative impact.