| > Seems like you are missing the point of pipeline and the Jenkinsfile concept, namely that the pipeline is part of the SCM. I guess I missed that Jenkins is heading that way. It's what Concourse does and I'm a fan of having CI/CD live in the repo. > For me the real advantage in pipeline is the organization folders support. You can tell Jenkins to scan all the repositories in your GitHub org and automatically create Jenkins jobs for any branches of any repositories that have a Jenkinsfile... PRs will automatically (subject to basic drive-by hack protection) be built and the commit will be tagged with the result. For PR-building on Concourse, the resource I'd recommend is: https://github.com/jtarchie/pullrequest-resource > we are providing some opinionated defaults (which is a change from the 1.x series) I see this more and more in the Java ecosystem and I think it's a good thing. > I might have a different view on that claim, but hey I'm significantly biased. Me too! :) > OTOH my personal view is that for the 99% of jobs pipeline is overkill I am starting to head in the other direction. We've historically fallen into creating "big ball of mud" build systems because it was just too hard to easily decompose and manage them as smaller units that could be rearranged quickly and safely. Concourse makes it so trivial that the gradient for what is easy points in the other direction. It is less painful to lay out a pipeline (a graph, really) of builds that are composed of small pieces, than to have one gigantic Build To Rule Them All. In Pivotal the practices around Concourse are evolving extremely quickly, because teams are discovering that it's really easy to delegate more and more to it. You start with a simple git->unit->feature->deploy pipeline, but soon you realise it's easy to assemble all sorts of things. The best is yet to come. |