Learn Groovy - Jenkins Pipeline & CI/CD

#Introduction

Jenkins is another reason Groovy stays relevant: the entire Jenkins CI/CD pipeline is written in Groovy. Every Jenkinsfile you see is Groovy code running on Jenkins.

Episode 13 covers declarative pipelines, stages and steps, agent configuration, shared libraries, and integration with Git, testing, and deployment automation.

#Declarative Pipelines

#Jenkinsfile Structure

pipeline {
    agent any
 
    stages {
        stage("Checkout") {
            steps {
                checkout scm
            }
        }
 
        stage("Build") {
            steps {
                echo "Membangun project"
                sh "gradle build"
            }
        }
 
        stage("Test") {
            steps {
                sh "gradle test"
            }
        }
    }
}

pipeline { agent any stages { ... } } opens the pipeline block; agent any uses whichever worker is available. Each stage defines a phase, and steps contains the commands to run — all of it is Groovy DSL.

#Post and Notifications

pipeline {
    agent any
    stages {
        stage("Build") {
            steps {
                sh "gradle build"
            }
        }
    }
    post {
        success {
            echo "Build sukses"
        }
        failure {
            echo "Build gagal"
        }
    }
}

post { success { ... } failure { ... } } runs notifications according to the final condition. This is where you can call Slack plugins, email, or external APIs to report build status.

#Agents and Environment

#Agent Configuration

pipeline {
    agent {
        docker {
            image "gradle:8-jdk17"
            args "-v /root/.gradle:/home/gradle/.gradle"
        }
    }
    stages {
        stage("Build") {
            steps {
                sh "gradle build"
            }
        }
    }
}

agent { docker { image "gradle:8-jdk17" } } runs the pipeline inside a Gradle container. Each stage can override the agent with agent { label "linux" } to run part of the pipeline on a specific worker.

#Shared Libraries

#Why Shared Libraries

As pipelines grow large, code duplication across projects becomes a problem. Shared libraries let you store common Groovy code in a single repository that many Jenkinsfiles can use:

// vars/notifikasiKanal.groovy
def panggil(String pesan) {
    echo "Notifikasi: ${pesan}"
}
 
// panggilan dari Jenkinsfile
notifikasiKanal("Deploy dimulai")

vars/notifikasiKanal.groovy defines a global method called from the Jenkinsfile. notifikasiKanal("Deploy dimulai") calls that method — this is Groovy metaprogramming that makes functions available without an explicit import.

#Complete Pipeline

#Combining Git, Test, and Deploy

pipeline {
    agent any
 
    stages {
        stage("Checkout") {
            steps {
                checkout scm
            }
        }
        stage("Test") {
            steps {
                sh "gradle test"
            }
        }
        stage("Build") {
            steps {
                sh "gradle build"
            }
        }
        stage("Deploy") {
            when {
                branch "main"
            }
            steps {
                sh "deploy-script.sh"
            }
        }
    }
    post {
        always {
            junit "build/test-results/**/*.xml"
        }
    }
}

when { branch "main" } restricts the Deploy stage to run only on the main branch, and junit "build/test-results/**/*.xml" publishes test results to the Jenkins dashboard. checkout scm fetches the code from Git automatically.

#Closing

Episode 13 showed Groovy's power in CI/CD: declarative pipelines with stages and steps, agent configuration including docker, shared libraries for code reuse, and Git, testing, and deployment integration in a single pipeline.

The key takeaways:

• A Jenkinsfile is a Groovy DSL with a pipeline, stages, and steps structure.
• agent determines the worker or container where the pipeline runs.
• environment defines pipeline variables.
• Shared libraries enable Groovy code reuse across projects.
• when { branch "main" } conditionally controls stage execution.
• The post block runs notifications and result reporting.

In episode 14 next, we'll discuss configuration, secrets, and environment — managing application configuration with Groovy, secure secret handling, external config sources, as well as per-environment behavior and runtime overrides.