DEV Community

Discussion on: Is Jenkins Pipelining Really This Messed Up??

Collapse
habereder profile image
Raphael Habereder

I know your pain. Having spent a surreal amount of time with Hudson/Jenkins over the last 12 years, there are countless things that bug me.

Jenkins pipeline groovy DSL uses a custom CPS interpreter with a few limitations during the interpretation of groovy. This means that it bypasses/overrides a lot of the standard implementation of groovy. It never felt like "real groovy" to me. I can't recount the times I opened my IDE and just coded groovy code, only to be frustrated to see it fail in Jenkins.

If you want to get closer to "real groovy", you'll have to work a lot with the @NonCPS Annotation, which itself brings a whole slew of different problems again if you mix your NonCPS Methods with regular CPS Steps.

Or the infamous parallel index-loop bug, which was declared as "feature", where when using a parallel step for an indexed loop, the index would always be at the max value, completely breaking your loop. There were many painful bugsFeatures like this that I encountered in my career.

What I have learned is, "don't try too complicated things and Jenkins will be good/ok to use". The moment you want to do anything that defies the typical "Jenkins CPS Step Glory", you are going to have a bad time.
Define your own steps, create a shared library and pray that it "just works". But don't overdo it with the library, or else you'll easily find yourself in maintenance hell.

I do love Jenkins, it has served me well in many a project, but nowadays? It would strongly depend on what I have to do. If I can use Concourse, ArgoCD, Drone or Tekton, I'll be super happy. Jenkins on the other hand has gone way down on my "happyness list" in the last years.