问题
What is the major difference between Job DSL Plugin and Pipeline Plugin
- both provide way to programmatic job creation
- which is the best to use as moving ahead and why?
- if both have similar functionality, do they have different use cases?
- Since Jenkins 2.0 is focusing on Pipelines as code, does this mean that job-dsl does not have a future or Pipeline Plugin is the next step in the Job DSL Plugin?
回答1:
I have extensive experience with both. A concise reply is that Job DSL has existed for much longer and was Netflix's open source solution for "coding" Jenkins. It allowed you to introduce logic and variables into scripting your Jenkins jobs and typically one would use these jobs to form some sort of "pipeline" for a particular project. This plugin received quite a bit of traction as a common way to enable job templating and scripting.
Jenkins Pipeline (2.0) is a new incarnation of a Jenkins job that is entirely based on a DSL and attempts to eliminate the need to stitch together multiple jobs to fill a single pipeline which was by far the most common use of Job DSL. Originally, with Pipeline DSL not offering many of the features that Job DSL did, and as mentioned above Job DSL would allow you to create Pipeline jobs, they could be used together to define a pipeline.
Today, IMO there is little reason to use Job DSL because Pipeline is the Jenkins-supported mechanism for scripting Jenkins pipelines and it has met or surpassed much of the functionality of Job DSL. New plugins are being developed natively for Pipeline, and those that don't are being encouraged by Jenkins developers to integrate with Pipeline. And Pipeline has several advantages:
- There is no need to "seed" jobs using Pipeline as there is with Job DSL since the Pipeline is the job itself. With Job DSL, it's just a script that creates other jobs.
- With Pipeline, you have features such as a parameterized manual input step, allowing you specify logic midstream within the pipeline
- The logic that can be included in a Job DSL is limited to creating the jobs themselves; whereas with Pipeline you can include logic directly inside the job.
- Job DSL is simply much more difficult to create a basic delivery pipeline using, for example, the Build Pipeline Plugin; using Pipeline your file will be smaller and syntax shorter. And if you're using Job DSL to create Pipeline jobs, I haven't seen a major value for that anymore given the templating features available out-of-the-box with Jenkins Pipeline.
Finally, Jenkins Pipeline is by far the most prevalent feature of Jenkins right now. Check out the Jenkins World 2016 agenda and you'll see approx. 50% of the sessions involve pipeline. None for Job DSL.
回答2:
My feeling is the ideal approach is to use both. Pipeline is the new native Jenkins feature to have jobs as code. However, if building Jenkins from scratch, those jobs still need to be created. This means Jenkins can't be 100% truly scripted and built from code.
What you can do is use JOB DSL to build the skeleton structure of all the jobs, then use pipeline for the implementation of the jobs. This will allow you to 100% script Jenkins, minus the initial seed job to be created.
Maybe, eventually we will be able to use pipeline to fully control Jenkins (security, configuration and even plugins). But until then, I think it is a good approach to use DSL and Pipeline.
回答3:
My preliminary answer based on very limited experience:
- Each uses a different Groovy DSL.
- Job DSL gives you a way to create other jobs according to a Groovy script. So if you want a set of X related jobs (e.g. a pipeline), you'll create one Job DSL job, write the script, run that job, and then you'll have those X jobs, plus the one to create those jobs. At that point, only the job you created directly has been run, the ones created by that job have not. OOTB, these jobs are not hidden the way Maven modules in a multi-module Maven job are hidden, but I understand there is at least a way to create a view and stick the jobs there.
- Pipeline DSL just hangs indefinitely in the 2 very different environments where I have tried it. :'( This is a known showstopper bug, as I understand--search and you will find some open bug tickets on this. Anywho, running the Pipeline job you create actually runs the pipeline, not generates a bunch of jobs like the Job DSL. So triggers to run the pipeline job are triggers to run the pipeline, not merely update the jobs it defines.
- Pipeline appears to be more widely used, judging from the download numbers. Of course, Pipeline is a default feature of Jenkins 2.0, which might account for the recent spike in downloads. The maintainers of Jenkins sure want you to use it.
So to recap: Job DSL's DSL is for creating jobs that form a pipeline, Pipeline Plugin's DSL defines the pipeline itself.
And to answer your question(s): Pipeline should be more widely supported in the future, looks more straightforward to me (the job is a job, not a metajob), and appears to have more features (including workflow). I would use it unless you hit the aforementioned showstopper bug of doom and cannot find a fix / workaround.
回答4:
There's one important distinction that's not been mentioned here so far: testing. With the job-dsl there's a means of testing the DSL code before committing it to SCM: https://github.com/sheehan/job-dsl-gradle-example - this allows a local test suite to be run on DSL code, as well as in Jenkins, before the code is run. As far as I'm aware, there is no equivalent in the native Pipeline approach.
来源：https://stackoverflow.com/questions/37657810/job-dsl-plugin-vs-pipeline-plugin