Hacker News Reader

Comment by serbrech | Hacker News Reader

I like the concept or pipeline, and I like that the definition can be checked in with the code, but :

* I don't like to couple the builds to a product

* Can I run the build locally? if something goes, how to I know if it's a bug in the pipeline script, the build server environment, or my code. I want reproducible builds.

View on HN

The popular/recommended pattern for using Jenkins pipeline is to abstract the course grained build "steps" out to shell scripts and to use Jenkins pipeline to orchestrate the whole build process by running these steps at the right time (in parallel blocks etc), capturing human approval, making it all "durable" (tolerant of restarts) etc etc. If you find yourself putting lots of complex build logic into a pipeline script, then you're probably doing something wrong.

Doing it this way reduces the tie to the "product" and also means that you can easily test the individual self-contained steps outside of the product.

I can confirm that this is the pattern that folks on Concourse have moved towards as well.

When the CI system has high-level primitives for showing and organising build graphs, it makes sense to surface those instead of burying them inside a relatively opaque build tool.

Many teams opt to keep most of the logic of their process inside shell scripts or build tools (like Maven or Make). I'm not sure if there is any standard way of defining a Pipeline in the way I think you are asking that is tool agnostic.

Building locally is a good one and thats something I am thinking about in the long term.

Reply on news.ycombinator.com