Jenkins - Setup Build Jobs

Jenkins - Pipeline Basics (Jenkinsfile)

While Jenkins supports various job types, the modern standard for defining build, test, and deployment processes is Jenkins Pipeline, using a domain-specific language (DSL) based on Groovy. Pipelines are defined in a text file called Jenkinsfile.

Why Pipeline?

• Pipeline as Code: The pipeline definition lives in version control (usually with your application code), providing history, reviewability, and resilience.
• Durability: Pipelines can survive Jenkins controller restarts.
• Extensibility: Leverage the full power of Jenkins plugins and Groovy scripting.
• Visualization: Clear visual representation of the workflow stages (especially with Blue Ocean).
• Flexibility: Supports complex workflows, conditional execution, parallelism, and user input.

There are two primary syntax variants: Declarative Pipeline and Scripted Pipeline. Declarative is newer, more structured, and generally recommended for its simplicity and clearer syntax. Scripted offers more flexibility via raw Groovy scripting.

Creating Your First Pipeline Job

Step 1: Go to the Jenkins dashboard and click ‘New Item’.

Step 2: Enter an item name (e.g., my-first-pipeline). Choose the ‘Pipeline’ option. Click ‘OK’.

Step 3: On the configuration page, scroll down to the ‘Pipeline’ section. Here you define where your Jenkinsfile comes from:

• Option A: Pipeline script (Inline): (Good for simple tests/demos) Write your pipeline script directly in the text box provided in the Jenkins UI.
• Option B: Pipeline script from SCM (Recommended): Select this to pull the Jenkinsfile from a Source Code Management system like Git. This is the standard practice for real projects.
• • SCM: Choose ‘Git’.
• • Repository URL: Enter the URL of your Git repository.
• • Credentials: Select credentials if the repository is private.
• • Branch Specifier: Specify the branch containing the Jenkinsfile (e.g., */main).
• • Script Path: The path to your pipeline file within the repository (default is Jenkinsfile in the root).

Basic Declarative Jenkinsfile Structure

A simple Declarative Jenkinsfile looks like this:

pipeline {
    agent any // 1. Define where the pipeline runs

    stages { // 2. Define the workflow stages
        stage('Checkout') { // 3. Define a specific stage
            steps { // 4. Define the actions within a stage
                echo 'Checking out code...'
                // Example: git url: '...', branch: '...', credentialsId: '...'
                // If using 'Pipeline script from SCM', checkout happens automatically
            }
        }
        stage('Build') {
            steps {
                echo 'Building the project...'
                // Example for Maven:
                // sh 'mvn clean package'
                // Example for Node.js:
                // sh 'npm install'
                // sh 'npm run build'
                // Example for Windows:
                // bat 'msbuild MySolution.sln /p:Configuration=Release'
            }
        }
        stage('Test') {
            steps {
                echo 'Running tests...'
                // Example for Maven:
                // sh 'mvn test'
                // Example for Node.js:
                // sh 'npm test'
            }
        }
    }

    post { // 5. Define actions after stages complete
        always {
            echo 'Pipeline finished.'
            // Example: Clean up workspace
            // cleanWs()
            // Example: Publish test results
            // junit '**/target/surefire-reports/*.xml'
        }
        success {
            echo 'Pipeline succeeded!'
            // Example: Send success notification
        }
        failure {
            echo 'Pipeline failed!'
            // Example: Send failure notification
        }
    }
}

Explanation:

1. agent: Specifies where the entire pipeline or a specific stage should execute. agent any means Jenkins will use any available agent. You can specify labels (agent { label 'linux' }), Docker images (agent { docker { image 'node:16' } }), Kubernetes pods, etc.
2. stages: Contains one or more stage blocks, representing logical parts of your workflow.
3. stage: Defines a distinct phase (e.g., ‘Build’, ‘Test’, ‘Deploy’). Stages are visualized in the Jenkins UI.
4. steps: Contains the actual commands to execute within a stage. Use built-in steps (echo, sh for shell scripts, bat for Windows batch, git, junit, etc.) or steps provided by plugins (docker.build, slackSend, archiveArtifacts).
5. post: Defines actions that run after the stages block completes, based on the pipeline’s status (always, success, failure, unstable, changed). Ideal for cleanup, notifications, and publishing reports.

Running the Pipeline

Step 4: Click ‘Save’ on the pipeline configuration page.

Step 5: Click ‘Build Now’ from the pipeline’s main page.

Step 6: Observe the build progress. You’ll see:

• Build History: Shows running and completed builds.
• Stage View: (Classic UI or Blue Ocean) Visualizes the progress through the defined stages.
• Console Output: Provides the detailed log of all commands and steps executed.

If the build fails, the stage view will highlight the failing stage, and the console output will contain error messages.

This covers the basics of creating and running Jenkins Pipelines. Subsequent chapters will explore adding testing, deployment, notifications, and more advanced features within the Jenkinsfile structure.