High level difference between workflow plugin and dsl plugin?
117 views
Skip to first unread message
David Karr
Feb 12, 2015, 7:27:19 PM2/12/15
to jenkins...@googlegroups.com
As part of a high-level presentation on Groovy that I'm giving to my organization, I was looking for a short statement that explains the difference between the workflow plugin and the dsl plugin, and the relationships they have with each other. Could someone give me a short statement covering that?
Baptiste Mathus
Feb 13, 2015, 7:49:22 AM2/13/15
to jenkins...@googlegroups.com
Well, in my mind they are orthogonal. You can configure your whole Jenkins instance through the Job DSL plugin, which as its name tries to say: "is a plugin using a Domain Specific Language, that is a somehow in that case a more human-readable than programmatic language version to create Jenkins jobs (and views, actually, and so on)"
The workflow-plugin is to be seen as a unique job [1]. Btw, according to the Job DSL plugin changelog, you can now create a workflow job using the Job DSL plugin.
Cheers
[1] Though, granted, the workflow-plugin by design is going to make less required to make many jobs in some situations (like synchronizing, etc.).
2015-02-13 1:27 GMT+01:00 David Karr <davidmic...@gmail.com>:
As part of a high-level presentation on Groovy that I'm giving to my organization, I was looking for a short statement that explains the difference between the workflow plugin and the dsl plugin, and the relationships they have with each other. Could someone give me a short statement covering that?
--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/c90013d7-64b0-4f46-ad72-b209e87f56b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jesse Glick
Feb 26, 2015, 10:10:39 AM2/26/15
to jenkins...@googlegroups.com
On Thursday, February 12, 2015 at 7:27:19 PM UTC-5, David Karr wrote:
I was looking for a short statement that explains the difference between the workflow plugin and the dsl plugin
It is unclear which plugin you are comparing Workflow to.
If the Job DSL plugin, then Baptiste is correct: these are complementary.
But perhaps you meant the Build Flow DSL, which is quite different—a common source of confusion! This was actually the main “prior art” we considered while designing Workflow, and they have many similarities: both involve orchestrating Jenkins build activities from a Groovy script run in-VM on the master, and the `stage` step in Workflow was even inspired by a similar Build Flow primitive. I would say that there are two key distinctions:
· Build Flow scripts cannot directly run any build steps. They rely on you having separate (freestyle, etc.) projects with traditional configuration, and just orchestrate those builds with some “glue” logic. Workflow also has a `build` step for this purpose (which needs to be fleshed out considerably), but its main design goal is letting you run build steps directly from the flow, so even a multistage pipeline can be described completely in one text file.
· Build Flow runs Groovy code synchronously in a Java thread. Thus, if Jenkins is restarted, your build is killed, just like a freestyle build would be. Workflow uses a custom-built (CPS) interpreter for Groovy that allows the flow and (in most cases) its individual steps to run piecemeal and asynchronously, surviving Jenkins restarts. In particular, the `sh` and `bat` steps are built using a fresh system (the Durable Task plugin) to allow them to survive Jenkins restarts and even slave channel reconnections, which is simply impossible for traditional Jenkins projects.
I would suggest you look over some of the presentations linked from the Workflow home page which give some context like this.
Les Mikesell
Feb 26, 2015, 12:25:42 PM2/26/15
to jenkinsci-users
On Thu, Feb 26, 2015 at 9:10 AM, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> But perhaps you meant the Build Flow DSL, which is quite different—a common
> source of confusion! This was actually the main “prior art” we considered
> while designing Workflow, and they have many similarities: both involve
> orchestrating Jenkins build activities from a Groovy script run in-VM on the
> master, and the `stage` step in Workflow was even inspired by a similar
> Build Flow primitive. I would say that there are two key distinctions:
And each seems to lack needed features provided by the other...
>
> But perhaps you meant the Build Flow DSL, which is quite different—a common
> source of confusion! This was actually the main “prior art” we considered
> while designing Workflow, and they have many similarities: both involve
> orchestrating Jenkins build activities from a Groovy script run in-VM on the
> master, and the `stage` step in Workflow was even inspired by a similar
> Build Flow primitive. I would say that there are two key distinctions:
> · Build Flow scripts cannot directly run any build steps. They rely on you
> having separate (freestyle, etc.) projects with traditional configuration,
> and just orchestrate those builds with some “glue” logic.
so you can't do things like polling scm changes to trigger builds or
archive artifacts from the multiple jobs you are orchestrating without
adding extra jobs just for those operations (which you'd expect the
top-level job to handle).
> Workflow also has
> a `build` step for this purpose (which needs to be fleshed out
> considerably), but its main design goal is letting you run build steps
> directly from the flow, so even a multistage pipeline can be described
> completely in one text file.
jobs it can start, so you can't ensure that that all are building the
same revision or find their results - or at least I don't see how to
do it.
> · Build Flow runs Groovy code synchronously in a Java thread. Thus, if
> Jenkins is restarted, your build is killed, just like a freestyle build
> would be. Workflow uses a custom-built (CPS) interpreter for Groovy that
> allows the flow and (in most cases) its individual steps to run piecemeal
> and asynchronously, surviving Jenkins restarts. In particular, the `sh` and
> `bat` steps are built using a fresh system (the Durable Task plugin) to
> allow them to survive Jenkins restarts and even slave channel reconnections,
> which is simply impossible for traditional Jenkins projects.
'durable' part available to everyone or just in the cloudbees
enterprise version?
--
Les Mikesell
lesmi...@gmail.com
Jesse Glick
Feb 26, 2015, 3:17:42 PM2/26/15
to jenkins...@googlegroups.com
On Thursday, February 26, 2015 at 12:25:42 PM UTC-5, LesMikesell wrote:
Workflow doesn't give you any access to the internals of the other
jobs it can start, so you can't ensure that that all are building the
same revision
or find their results
Jenkins master restarts haven't been a real issue for me, but is the
'durable' part available to everyone or just in the cloudbees
enterprise version?
Everyone, this is a basic part of Workflow. Jenkins Enterprise does add a related but distinct feature: restart from checkpoint.
Reply all
Reply to author
Forward
0 new messages