when/why use DSL for Jenkins

[suu....@oracle.com]

Warning: I can barely spell DSL, but I have a task to evaluate if we can use it, and in what situation.

I've read the plugin documentation, the DSL tutorial, but lingering questions remain:

1. is DSL just for generating new Jenkins jobs? has anyone use it for some other usage. Please point me to some papers or RFCs (Request for Comments)

2. I've seen examples of it generating new jobs, but can you give me real examples of why one would use it, versus creating the job(s) by copying?

    For example, I have a product with 49 branches to build. That would be a good use case? But those branches are created over years and years. Creation is about one new job/branch every 3 to 6 months. 

3. what convinces you to decide to use DSL instead for your situation? your thought process.

thanks in advance

Suu

[Andrew McLaughlin]

Hi Suu,

Here’s some light reading on what DSL are (as part of Groovy), how powerful it is (you can design your own DSL) and how to use existing ones (like Jobs).

http://docs.groovy-lang.org/docs/latest/html/documentation/core-domain-specific-languages.html

Andrew

--
You received this message because you are subscribed to the Google Groups "job-dsl-plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to job-dsl-plugi...@googlegroups.com.
To post to this group, send email to job-dsl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/job-dsl-plugin/e1bafab8-033e-45cd-94a3-0628bd3def61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[suu....@oracle.com]

Note that I'm not trying to be an expert in DSL or groovy (later when i get deeply into it).

At this stage, I'm trying to "play the Advisor role": to advise people when and whether use DSL at all.

[Fiouz]

Job copying vs Job-DSL based generation is like code duplication vs object oriented programming: copying is easier to achieve but very difficult to manage evolution/consistency over time.

Unless you have snapshot requirements for the different jobs (eg once created, no need to maintain consistency), you are likely to spend time on job maintenance when using a simple job copying approach compared to a factory facility (such as job-dsl). 

On Thu, 6 Oct 2016, 09:32 , <suu....@oracle.com> wrote:

Note that I'm not trying to be an expert in DSL or groovy (later when i get deeply into it).

At this stage, I'm trying to "play the Advisor role": to advise people when and whether use DSL at all.

--

You received this message because you are subscribed to the Google Groups "job-dsl-plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to job-dsl-plugi...@googlegroups.com.
To post to this group, send email to job-dsl...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/job-dsl-plugin/3bb0cf0b-a1bc-430d-bf88-7004feaebd25%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

--
Fiouz

[Victor Martinez]

We have different use cases in our case:

- I use JobDSL to reuse the same administrative tasks in several jenkins instances by storing that setup in one single repo. 

- Besides of that, teams are using JobDSL to script their CI/CD pipelines and apply them when a new Feature Branch is created, in our case we use Git and therefore we analyse whether that particular Feature Branch has been created if so, then there is a post hook to trigger a Seed Job in jenkins which filter the branch name and create those Jobs automatically.

There are some details you can find useful to look at in the below wiki:

- https://github.com/jenkinsci/job-dsl-plugin/wiki/Talks-and-Blog-Posts

JobDSL is somehow keeping the same standard as using the Jenkins UI to generate jobs, therefore people are quite familiar with the UI, but you cannot escalate accordingly when you need to create/edit/remove a bunch of jobs. Besides of that, JobDSL support testing and it means you can verify/test your DSL scripts locally before pushing them to any jenkins instance. IMO, that's the key strength of JobDSL.

My two cents