Four Practical Differences Between Declarative and Scripted Jenkins Pipelines

If you are reading this blog post, you are likely looking for the practical differences between scripted and declarative Jenkins pipelines, and you have come to the right place. The article outlines four concrete distinctions and demonstrates them with code examples and screenshots.

Why two pipeline types? Scripted pipelines were the first implementation of pipelines as code in Jenkins, built on a generic Groovy DSL without a fixed structure. Declarative pipelines impose a defined structure, which may seem limiting but offers clearer conventions.

1. Code validation at pipeline start

pipeline {
agent any
stages {
stage("Build") {
steps {
echo "Some code compilation here..."
}
}
stage("Test") {
steps {
echo "Some tests execution here..."
echo 1
}
}
}
}

Running this pipeline fails early because the String parameter validation triggers an error before any stage executes, saving time.

2. Restarting from a specific stage

Declarative pipelines support a “Restart from stage” feature. After a failed test, you can restart the pipeline from the Test stage without rebuilding the Build artifacts.

node {
stage("Build") {
echo "Some code compilation here..."
}
stage("Test") {
echo "Some tests execution here..."
echo 1
}
}

The scripted version lacks a restart option, illustrating a usability advantage of declarative pipelines.

3. Options block in declarative pipelines

Both pipeline types can use timestamps, ANSI color, and timeout, but declarative syntax keeps options separate from the pipeline logic.

pipeline {
agent any
options {
timestamps()
ansiColor("xterm")
}
stages {
stage("Build") {
options { timeout(time: 1, unit: "MINUTES") }
steps { sh 'printf "\e[31mSome code compilation here...\e[0m\n"' }
}
stage("Test") {
options { timeout(time: 2, unit: "MINUTES") }
steps { sh 'printf "\e[31mSome tests execution here...\e[0m\n"' }
}
}
}

The equivalent scripted version nests the same functionality inside timestamps , ansiColor , and timeout blocks.

4. Skipping stages with a when block

Declarative pipelines can conditionally skip stages using a when block, e.g., executing the Test stage only when env.FOO == "bar" . The scripted counterpart requires an explicit if statement, which does not truly skip the stage but conditionally creates it.

pipeline {
agent any
options { timestamps(); ansiColor("xterm") }
stages {
stage("Build") {
options { timeout(time: 1, unit: "MINUTES") }
steps { sh 'printf "\e[31mSome code compilation here...\e[0m\n"' }
}
stage("Test") {
when { environment name: "FOO", value: "bar" }
options { timeout(time: 2, unit: "MINUTES") }
steps { sh 'printf "\e[31mSome tests execution here...\e[0m\n"' }
}
}
}

The article concludes that declarative pipelines generally provide clearer structure, built‑in validation, restart capabilities, and conditional execution, making them preferable to scripted pipelines for most use cases.