Declarative Pipelines (Jenkinsfile)

Why Pipelines?

A freestyle job config lives in Jenkins. A Jenkinsfile lives in your repository, so everyone can review and version it. That is the pipeline as code philosophy.

A Minimal Declarative Pipeline

pipeline {
    agent any

    stages {
        stage('Checkout') {
            steps { echo 'Getting the code' }
        }
        stage('Build') {
            steps { echo 'Building' }
        }
        stage('Test') {
            steps { echo 'Running tests' }
        }
    }
}

Key Declarative Blocks

• agent - where it runs: any, a label, or docker.
• stages / stage - named phases shown in the UI.
• steps - the commands executed inside a stage.
• post - actions after the pipeline: always, success, failure.
• environment - variables available to all stages.
• parameters - inputs the user fills when building.

Pipeline Triggers

pipeline {
    agent any
    triggers {
        cron('H/15 * * * *')
    }
    stages {
        stage('Build') { steps { sh 'make build' } }
    }
}

The H/15 hash symbol spreads builds evenly instead of every machine running at :00.

Using the Scripted Form

The older scripted syntax uses Groovy directly: node { stage('Build') { sh 'make' } }. Learn it for complex logic, but prefer declarative for clarity.

Key Points

• Check the Jenkinsfile in with your source code - it is the source of truth.
• Declarative pipelines are easier to read and version well.
• post blocks are where you send notifications or clean up.