Migrate from Jenkins Multijob to Pipeline plug-in

Question

Currently we are using Jenkins CI 1.643 (I believe) with the Multijob plugin and Job DSL.
A collection of jobs is generated using Job DSL, as well as a multijob that contains all the other jobs in a specific order (build, analysis, unit test, integration test, etc.).

I'm interested in upgrading to Jenkins 2 and using the Pipeline plug-in (previously known as the Workflow plug-in). The Pipeline plug-in offers a nice graphical representation and also offers some more advanced features that we currently do not have (like the "pause" action, that requires human interaction). The Blue Ocean project also seems to be very sleek, but requires the Pipeline plug-in.

Regarding the migration, I have a few questions:

• Should I keep using Job DSL? We have a really nice templating mechanism created in Groovy so we only have to enter a few details about the product (like the compiler being used and certain quality thresholds). I think I would like to keep this.
• Is there a guide to "migrate" from the Multijob plug-in to the Pipeline plug-in?
• What are the things I should keep in mind? (key differences between the plug-ins.)

Ivatts

Just start writing the pipeline script and ask StackOverflow where you have concrete problems. – Teran

I would expect that this is a common task. That is why I'd expect a guide of some kind. Unfortunately I could not find a guide for it myself, but perhaps my search skills let me down. – Ivatts

I'm not aware of a guide (but looking for such things is kind of "against the stackoverflow rules"). I managed to replace all JobDSL with pipeline DSL. But certainly, the support in the different plugins is by far not that good (but will certainly improve). Regarding multijob, have a look at this answer. – Teran

@ArnoMoonen I am about to migrate as well. I would have expected some migration plugin or a plugin to export and convert existing job configurations. I also did not find anything until now. – Splanchnology

Answer 1

Not a complete answer, but:

We have a really nice templating mechanism created in Groovy so we only have to enter a few details about the product (like the compiler being used and certain quality thresholds). I think I would like to keep this.

The equivalent in Pipeline would be to create a Groovy library abstracting the common aspects of your projects, and call it from short main scripts in various jobs that just pass different arguments.

Should I keep using Job DSL?

There are still reasons to use Job DSL with Pipeline in certain cases: for example, if you want to automatically generate an array of jobs based on some computed criteria.

Kokanee