Declarative pipelines or Scripted Pipelines

Scripted Pipeline
	

Scripted syntax is an initial way that Pipeline-as-code have been done in Jenkins. Its Imperative syntax which means it is based on defining the logic and to program the flow in the pipeline script itself. It is also more dependent on the Groovy constructs and language.

// Scripted Pipeline
node('worker_node1') { 
    stage('Source') { 
            // Get code 
            git 'git@github.com:/home/git/repositories/workshop.git'
    }
    stage('Compile') { 
            //Compile and do unit testing 
            sh "mvn clean package test"
    } 
}

• Generally fewer sections and less specification needed
• Capability to use more procedural code
• More like creating a program
• Traditional pipeline-as-code model, so more familiar and backward compatible
• More flexibility to do custom operations if needed
• Able to model more complex workflows and pipelines

• More programming required in general
• Syntax checking limited to the Groovy language and environment
• Further away from the traditional Jenkins model
• Potentially more complex for the same workflow if it can be comparably done in a Declarative Pipeline

The declarative syntax is a newer option in Jenkins. Pipelines coded in the declarative style are arranged in clear sections that describe (or “declare”) the states and outcomes that you want in the major areas of the pipeline, rather than focusing on the logic to accomplish it.

// Declarative Pipeline
pipeline {
   agent {label 'worker_node1'}
        stages {
            stage('Source') { // Get code 
                      steps { 
                        // get code from our Git repository
                        git 'git@github.com:/home/git/repositories/workshop.git'
                      }
                }
            stage('Compile') { //Compile and do unit testing 
                      steps {
                        // run MVN to execute compile and unit testing 
                        sh "mvn clean package test"
            } 
        } 
    } 
}

• More structured—closer to the traditional sections of Jenkins web forms
• More capability to declare what is needed, so arguably more readable
• Can be generated through the Blue Ocean graphical interface
• Contains sections that map to familiar Jenkins concepts, such as notifications
• Better syntax checking and error identification
• Increased consistency across pipelines

• Less support for iterative logic (less like a program)
• Still evolving (may not support or have constructs for things you would do in traditional Jenkins)
• More rigid structure (harder to handle custom pipeline code)
• Currently not well suited for more complex pipelines or workflows

The declarative model should be easier to learn and maintain for new pipeline users or those wanting more ready-made functionality like the traditional Jenkins model. This comes at the price of less flexibility to do anything not supported by the structure. Declarative support scripted syntax within script block of pipeline. Checkout the official documentation link for more details about the syntax.