Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Migrate from Jenkins Multijob to Pipeline plug-in

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.)
like image 399
Arno Moonen Avatar asked Jun 10 '16 09:06

Arno Moonen


People also ask

What is the difference between freestyle job and pipeline?

In contrast to freestyle jobs, pipelines enable you to define the whole application lifecycle. Pipeline functionality helps Jenkins to support continuous delivery (CD). The Pipeline plugin was built with requirements for a flexible, extensible, and script-based CD workflow capability in mind.

What are the 3 types of pipelines in Jenkins?

Different Types of Jenkins CI/CD Pipelines. Scripted Pipeline. Declarative Pipeline.


1 Answers

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.

like image 179
Jesse Glick Avatar answered Nov 15 '22 06:11

Jesse Glick