How are Pipelines not first class in Jenkins? Pipelines are provided in the default installation and they are the first thing we talk about in the docs https://jenkins.io/doc/pipeline/tour/hello-world/
Admittedly I ditched jenkins before pipelines became a full feature, but my understanding of them in jenkins was that they are mostly for scheduling of jobs.
IE, run job A after job B
Concourse passes inputs, outputs and resources between jobs as the ONLY STATE, and jobs trigger based off of changes on resources or the availability of new inputs.
I think that when you sit down and look at the two products, jenkins is great at running scripts, and concourse is great at managing code versions.
In the end we actually run both concouse + a script runner; this allows concourse to manage the tagging, builds, releases, and testing; but still allows us to run ad hoc scripts that concourse doesn't do well.
I'd be interested in taking another look at jenkins now that pipelines and the groovy DSL is solidified, but I get the idea that they still fill slightly different needs
I have to agree with the poster. Piplines are very definitely not first-class objects:
- There is no way (in the default installation) of re-running a stage without running the whole job again.
- I can't see the history of a stage.
- Pipelines are a plugin, that only relatively recently became a default one
- They seems be the anointed new path, but live side-by-side with other branching methods like the Matrix plugin at this point.
This is all in-line with the "everything is a plugin" methodology, but in my mind that way of thinking is one of the biggest hindrances to Jenkins, second only to the lack of a real database powering it.
Admittedly I ditched jenkins before pipelines became a full feature, but my understanding of them in jenkins was that they are mostly for scheduling of jobs. IE, run job A after job B
Concourse passes inputs, outputs and resources between jobs as the ONLY STATE, and jobs trigger based off of changes on resources or the availability of new inputs.
I think that when you sit down and look at the two products, jenkins is great at running scripts, and concourse is great at managing code versions.
In the end we actually run both concouse + a script runner; this allows concourse to manage the tagging, builds, releases, and testing; but still allows us to run ad hoc scripts that concourse doesn't do well.
I'd be interested in taking another look at jenkins now that pipelines and the groovy DSL is solidified, but I get the idea that they still fill slightly different needs