Four Practical Differences Between Scripted and Declarative Jenkins Pipelines

If you are reading this blog post, you are probably looking for the practical differences between scripted and declarative pipelines in Jenkins; this article presents the four most tangible distinctions and demonstrates them with code snippets and screenshots.

1. Code validation at pipeline start – Declarative pipelines are validated before any stage runs, causing the build to fail early when a required parameter type is missing. The following declarative example triggers a validation error because the String parameter is not supplied:

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

Running the same logic in a scripted pipeline does not perform this early validation, so the pipeline proceeds until the steps themselves fail:

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

2. Restarting from a specific stage – Declarative pipelines support the “Restart from stage” feature, allowing you to re‑run only the Test stage while reusing the workspace from the previous build. The UI shows a “Restart Test” button and skips the Build stage. Scripted pipelines lack this capability; they always execute all defined stages.

3. Options block – Declarative pipelines keep pipeline options (e.g., timestamps, ANSI color output, and per‑stage timeouts) separate from the steps, as shown below:

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 pipeline can achieve the same behavior, but the options must be embedded inside the pipeline logic:

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

4. Skipping stages with a when block – Declarative pipelines can conditionally skip a stage using the when directive, for example executing the Test stage only when env.FOO == "bar" :

pipeline {
    agent any
    options { timestamps(); ansiColor("xterm") }
    stages {
        stage("Build") { /* … */ }
        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"' }
        }
    }
}

In a scripted pipeline the same conditional logic requires an explicit if statement, and the stage is not truly “skipped” but simply not defined when the condition is false:

node {
    timestamps {
        ansiColor("xterm") {
            stage("Build") { /* … */ }
            if (env.FOO == "bar") {
                stage("Test") {
                    timeout(time: 2, unit: "MINUTES") { sh 'printf "\e[31mSome tests execution here...\e[0m\n"' }
                }
            }
        }
    }
}

These four differences illustrate why declarative pipelines often provide a clearer, more maintainable, and feature‑rich experience compared with scripted pipelines, though both can achieve the same end results.

Conclusion – The article lists the four major distinctions between declarative and scripted Jenkins pipelines and invites readers to choose the style that best fits their workflow.