Jenkins for Students: How to Automate Software Builds and Tests

1. Introduction

Every developer remembers the anxiety of working on a group programming project where everyone’s code worked fine on their personal laptop, but everything shattered into cryptic errors once merged together the night before submission. One teammate used an outdated Java version, another modified an interface without telling anyone, and a third forgot to commit a critical dependency.

Software engineering teams in the tech industry face this exact challenge every day, but on a massive scale. To solve it, engineering organizations rely on automated, repeatable processes that build, test, and validate software every single time an engineer pushes a code change. Instead of guessing whether an application compiles or passes its test suite, teams use automated continuous feedback loops. At the center of this industry-standard practice sits Jenkins, an open-source automation server that powers modern Continuous Integration and Continuous Delivery (CI/CD) workflows. For university students, recent graduates, and aspiring engineers learning through educational platforms like DevOpsSchool, mastering Jenkins bridges the gap between writing simple code assignments and understanding real-world software delivery pipelines. Learning Jenkins for students is not merely about clicking buttons on a dashboard; it provides foundational insight into build automation, regression testing, pipeline design, configuration management, and the collaborative operational culture known as DevOps. By learning to automate builds and tests early in your academic journey, you develop the disciplined habits top software engineering teams expect from junior hires.

2. What Is Jenkins?

Jenkins is a self-contained, open-source automation server designed to coordinate and automate tasks throughout the software development lifecycle. Written in Java, it acts as an orchestration engine that watches your code repositories for updates, triggers execution routines, runs test suites, packages binary distributions, and reports the status back to the engineering team.

Manual vs. Automated Builds

To understand why Jenkins is essential, consider the contrast between manual and automated workflows:

Aspect	Manual Build Process	Automated Build Process (Jenkins)
Execution Trigger	Developer manually types commands in a local terminal	Automatically triggered by a Git push, pull request, or schedule
Environment Consistency	Highly variable; depends on local machine state and configurations	Standardized across reproducible build environments
Test Verification	Easily skipped, forgotten, or executed incompletely	Enforced automatically before code is accepted or packaged
Feedback Loop	Slow; bugs often discovered days or weeks later	Fast; failures reported within minutes of a code push
Human Effort	Repetitive, prone to human error, and time-consuming	“Set and forget” pipeline definition executed automatically

How Jenkins Supports CI/CD

Jenkins fundamentally supports two stages of modern software delivery:

Continuous Integration (CI): Developers integrate their code into a shared repository frequently—often multiple times a day. Jenkins verifies each check-in by automatically building the application and running automated tests. This detects bugs early and pinpoints the exact commit that introduced a defect.
Continuous Delivery (CD): Once the build and test stages pass, Jenkins can automatically stage the packaged application for release or deploy it directly to staging or production environments.

The Role of an Orchestrator

A common misconception among beginners is that Jenkins compiles your code or executes unit tests natively. In reality, Jenkins is an orchestrator, not a compiler. Jenkins does not inherently know how to compile Java, package Python, or transpile TypeScript.

Instead, Jenkins coordinates specialized tools and plugins. It uses a Version Control System (VCS) like Git to fetch code, hands the code over to a build tool like Apache Maven or Gradle to compile and test it, runs test runners like JUnit, and parses the resulting test reports to determine if the pipeline passed or failed. Jenkins provides the environment, schedules the tasks, records the output, and signals success or failure.

3. Understanding Builds, Automated Tests, and CI

Before configuring an automated server, you must understand the core concepts behind the lifecycle of an automated run.

+---------------+      Git Push      +--------------------+
|   Developer   | -----------------> |  Code Repository   |
| (Local Code)  |                    |      (GitHub)      |
+---------------+                    +--------------------+
                                               |
                                        Webhook Event
                                               v
+---------------------------------------------------------+
|                    Jenkins Controller                   |
|                                                         |
|  +----------------+   +----------------+   +---------+  |
|  | 1. Checkout Git|-->| 2. Maven Build |-->| 3. Test |  |
|  +----------------+   +----------------+   +---------+  |
|                                                 |       |
|                                            JUnit XML    |
|                                                 v       |
|  +----------------+                       +----------+  |
|  | Fast Feedback  |<----------------------| 4. Report|  |
|  | (Pass / Fail)  |                       +----------+  |
|  +----------------+                                     |
+---------------------------------------------------------+

What Is a Software Build?

A software build transforms source code files written by humans into executable machine code, bytecode, or deployable software packages (such as .jar, .war, or .zip files).

A build process includes:

Dependency Management: Downloading and linking external libraries, frameworks, and packages specified by the project (for example, via Maven’s pom.xml or Node’s package.json).
Compilation: Converting human-readable source code into machine-executable formats while verifying syntax and interface contracts.
Resource Processing: Copying and formatting static assets, configuration files, and properties.
Packaging: Assembling the compiled code and resources into an archive ready for execution or distribution.

The Testing Pyramid

Automated testing evaluates software behavior against expected outcomes without requiring human testers to click through an application manually. Automated tests fall into three primary categories:

Unit Tests: These verify the smallest testable parts of an application—such as a single function, class, or method—in complete isolation from databases, networks, or file systems. They execute in milliseconds and should make up the majority of your test suite.
Integration Tests: These verify that distinct components, modules, or services function correctly together (for example, verifying that an authentication class interacts properly with a test database).
End-to-End (E2E) / System Tests: These exercise the entire application flow from start to finish, mimicking real user journeys through user interfaces or public API endpoints.

The Cost of Build and Test Failures

In a manual setup, if a developer breaks a calculation inside a core helper function, that defect might go unnoticed until another teammate pulls the changes days later—or worse, after the software is handed to a customer.

Continuous Integration enforces early feedback. Suppose a student updates a discount calculation in an e-commerce class:

The student commits and pushes the code change to Git.
Jenkins detects the push and immediately starts an automated build.
Jenkins invokes the build tool to run all unit tests.
An existing test checks: calculateDiscount(100, 0.20) and expects 80. The new code returns 20.
The test runner registers an assertion error and terminates with an exit code indicating failure.
Jenkins halts the pipeline, marks the build as Failed (Red), and notifies the developer within minutes.
The developer reviews the test failure output, fixes the logic error, pushes the correction, and Jenkins turns Healthy (Green).

4. How Jenkins Works: Architecture and Core Components

Jenkins uses a distributed, modular architecture capable of scaling from a single laptop to thousands of servers across enterprise data centers.

                     +---------------------------------------+
                     |          Jenkins Controller           |
                     |  - Web UI & HTTP Dashboard            |
                     |  - Configuration & Plugin Engine      |
                     |  - Build Job Scheduler                |
                     |  - Credentials Vault                  |
                     +---------------------------------------+
                                  /            \
                      Work Request /              \ Work Request
                                  /                \
                                 v                  v
                 +----------------------+    +----------------------+
                 |     Agent Node 1     |    |     Agent Node 2     |
                 |  (Build Environment) |    |  (Build Environment) |
                 |  - Git, JDK, Maven   |    |  - Docker, Python    |
                 |  - Executes Tasks    |    |  - Executes Tasks    |
                 +----------------------+    +----------------------+

Core Components

Controller (formerly Master): The brain of the Jenkins installation. The controller provides the web UI, manages plugins, schedules build jobs, stores job definitions and build history, handles credentials, and assigns work tasks.
Agents (formerly Slaves): Worker machines or containers that connect to the controller and carry out the physical execution of build steps. Agents keep heavy compilation tasks off the controller. In small learning environments, Jenkins provides a built-in node directly on the controller to run jobs locally. However, production environments assign workloads to isolated agents for security and performance.
Jobs and Pipelines: A job (or item) is any automated task sequence managed by Jenkins. A pipeline is an advanced, user-defined model of a continuous delivery path, structured into sequential stages such as Build, Test, and Deploy.
Workspaces: An isolated directory on the file system of the machine executing the build. Jenkins creates a workspace for each job, checks out your project’s source code into it, runs tools against it, and cleans it up when instructed.
Plugins: Jenkins is built on an extensible plugin system. The base installation has minimal features; plugins provide integration with tools like Git, GitHub, Docker, Maven, Slack, and JUnit reporting.
Build History and Console Output: Every time a job runs, Jenkins creates an immutable historical record labeled with a sequential build number (#1, #2, #3). Jenkins captures the full terminal standard output (stdout) and standard error (stderr) logs, allowing you to debug exactly what happened during execution.
Credentials Management: A centralized, encrypted vault inside Jenkins that lets you store API keys, SSH private keys, and passwords. Jobs reference these secrets securely via IDs without ever hardcoding sensitive tokens into your project source code.

5. Setting Up Jenkins for Learning

To learn Jenkins step by step, you need a local sandbox environment.

System Requirements

Before beginning, confirm your machine meets these basic requirements:

Operating System: Linux (Ubuntu/Debian, CentOS/RHEL), macOS, or Windows 10/11 (with WSL2 recommended).
Memory (RAM): Minimum 2 GB to 4 GB allocated for Jenkins and your build tools.
Disk Space: At least 10 GB free for Jenkins, runtime logs, dependencies, and local git clones.
Runtime: A supported Java Development Kit (JDK) or Java Runtime Environment (JRE). Modern versions of Jenkins require Java 17 or Java 21.

Setup Methods: Native vs. Docker

Students typically choose between two setups:

Docker Container (Recommended for Students): Running Jenkins inside an official container isolates the automation server from your local operating system, avoids dependency conflicts, and allows you to tear down and recreate environments in seconds.
Native Host Installation: Installing Java and the Jenkins package directly on your operating system using package managers (apt, brew, or native installers).

Method A: Running Jenkins via Docker

If you have Docker Desktop installed, run this command in your terminal:

Bash

docker run -d \
  --name jenkins-learning \
  -p 8080:8080 \
  -p 50000:50000 \
  -v jenkins_home:/var/jenkins_home \
  jenkins/jenkins:lts-jdk17

-p 8080:8080: Exposes the Jenkins web dashboard on port 8080.
-p 50000:50000: Allows external Jenkins agents to communicate with the controller.
-v jenkins_home:...: Mounts a persistent Docker volume so your pipeline configurations, job history, and plugin settings survive container restarts.

Method B: Native Installation on Ubuntu/Debian Linux

For a native install on Linux, verify that Java 17 is present:

Bash

# Update repositories and install OpenJDK 17
sudo apt-get update
sudo apt-get install -y openjdk-17-jdk

# Verify Java version
java -version

Next, add the official Jenkins Debian repository key, register the repository sources list, update your packages, and install Jenkins:

Bash

sudo wget -O /usr/share/keyrings/jenkins-keyring.asc \
  https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key

echo "deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
  https://pkg.jenkins.io/debian-stable binary/" | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null

sudo apt-get update
sudo apt-get install -y jenkins

# Enable and start the Jenkins service
sudo systemctl enable jenkins
sudo systemctl start jenkins

Initial Administrator Setup

Once Jenkins starts, complete the setup wizard:

Open a browser and navigate to http://localhost:8080.
Unlock Jenkins: The browser displays a screen asking for an initial administrator password.
- If running natively on Linux:Bashsudo cat /var/lib/jenkins/secrets/initialAdminPassword
- If running via Docker:Bashdocker exec jenkins-learning cat /var/jenkins_home/secrets/initialAdminPassword
Copy the 32-character alphanumeric string, paste it into the setup screen, and click Continue.
Customize Jenkins: Click Install suggested plugins. This installs the default plugins for Git, Pipeline support, credentials, and common dashboard utilities.
Create First Admin User: Fill out the form with a username, password, full name, and email address (for example, studentadmin). Avoid relying on the temporary admin account.
Instance Configuration: Confirm the default URL (http://localhost:8080) and select Save and Finish. Your Jenkins dashboard is ready.

6. Prepare a Sample Application for Automation

To understand Jenkins build automation, you need an application project to build and test. We will use a standard Java application configured with Apache Maven.

Standard Maven Project Directory Structure

Maven relies on a standard directory layout. Create this structure locally on your workstation or in a new Git repository:

Plaintext

simple-java-app/
├── pom.xml
└── src
    ├── main
    │   └── java
    │       └── com
    │           └── devopsschool
    │               └── Calculator.java
    └── test
        └── java
            └── com
                └── devopsschool
                    └── CalculatorTest.java

pom.xml: The Project Object Model file containing project configuration, dependencies, and build plugins.
src/main/java: Stores your application’s production source code.
src/test/java: Stores automated test suites, such as unit tests.

1. The Build Configuration (`pom.xml`)

This minimal pom.xml configures a Java project with the modern JUnit 5 (Jupiter) testing framework and the Maven Surefire plugin for running tests:

XML

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
         https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.devopsschool</groupId>
    <artifactId>simple-java-app</artifactId>
    <version>1.0.0</version>
    <packaging>jar</packaging>

    <properties>
        <maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <junit.version>5.10.2</junit.version>
    </properties>

    <dependencies>
        <!-- JUnit Jupiter API & Test Engine -->
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <version>${junit.version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <!-- Maven Surefire Plugin to execute tests during the build lifecycle -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>3.2.5</version>
            </plugin>
        </plugins>
    </build>
</project>

2. The Application Code (`Calculator.java`)

Place this file in src/main/java/com/devopsschool/Calculator.java:

Java

package com.devopsschool;

public class Calculator {

    public int add(int a, int b) {
        return a + b;
    }

    public int subtract(int a, int b) {
        return a - b;
    }

    public int multiply(int a, int b) {
        return a * b;
    }

    public double divide(int a, int b) {
        if (b == 0) {
            throw new IllegalArgumentException("Division by zero is not allowed.");
        }
        return (double) a / b;
    }
}

3. The Unit Test Suite (`CalculatorTest.java`)

Place this file in src/test/java/com/devopsschool/CalculatorTest.java:

Java

package com.devopsschool;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;

public class CalculatorTest {

    private Calculator calculator;

    @BeforeEach
    void setUp() {
        calculator = new Calculator();
    }

    @Test
    @DisplayName("Test addition of two integers")
    void testAdd() {
        assertEquals(15, calculator.add(10, 5), "10 + 5 should equal 15");
    }

    @Test
    @DisplayName("Test subtraction of two integers")
    void testSubtract() {
        assertEquals(5, calculator.subtract(10, 5), "10 - 5 should equal 5");
    }

    @Test
    @DisplayName("Test division by zero throws exception")
    void testDivideByZero() {
        assertThrows(IllegalArgumentException.class, () -> {
            calculator.divide(10, 0);
        }, "Dividing by zero must throw IllegalArgumentException");
    }
}

Initialize a local Git repository, commit these files, and push them to a Git hosting provider such as GitHub, GitLab, or Gitea:

Bash

git init
git add .
git commit -m "Initial commit of student calculator project with unit tests"
git branch -M main
# Add your remote and push
# git remote add origin https://github.com/<your-username>/simple-java-app.git
# git push -u origin main

7. Create Your First Jenkins Job

Before jumping into code-based pipelines, it helps to understand what a Jenkins job looks like under the hood.

Freestyle Jobs vs. Pipeline Jobs

When creating a job in Jenkins, you will see several options:

Freestyle Project: The legacy, UI-driven way to configure builds in Jenkins. You configure Git repositories, shell commands, and post-build actions using forms and dropdown menus in the browser. While easy for beginners to understand, Freestyle jobs cannot be version-controlled, reviewed, or easily migrated.
Pipeline Project: The modern, production-standard approach. The entire workflow is written as code using a domain-specific language (DSL) and stored directly in your Git repository alongside your application code.

Exploring a Basic Freestyle Build (Walkthrough)

To understand how Jenkins interacts with tools on the underlying host, create a temporary Freestyle job:

On the Jenkins dashboard, click New Item.
Enter the name my-first-freestyle-job, select Freestyle project, and click OK.
Under General, add a short description: Testing basic shell execution.
Scroll to the Build Steps section, click Add build step, and select Execute shell (or Execute Windows batch command if running natively on Windows).
Enter a simple command:Bashecho "Running build on agent: $(hostname)" echo "Current workspace directory: $(pwd)" java -version
Click Save.

Running the Job and Inspecting Output

On the left navigation sidebar of your new job, click Build Now.
Notice that a new item appears in the Build History box: #1.
Click the #1 link, then select Console Output.

Plaintext

Started by user studentadmin
Running as SYSTEM
Building in workspace /var/jenkins_home/workspace/my-first-freestyle-job
[my-first-freestyle-job] $ /bin/sh -xe /tmp/jenkins847291048293.sh
+ echo 'Running build on agent: jenkins-learning'
Running build on agent: jenkins-learning
+ echo 'Current workspace directory: /var/jenkins_home/workspace/my-first-freestyle-job'
Current workspace directory: /var/jenkins_home/workspace/my-first-freestyle-job
+ java -version
openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment Temurin-17.0.10+7 (build 17.0.10+7)
OpenJDK 64-Bit Server VM Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)
Finished: SUCCESS

The console output shows every command executed by Jenkins, along with its standard output, standard error, and exit status. An exit code of 0 results in Finished: SUCCESS (represented by a blue or green ball depending on your UI theme). Any non-zero exit code stops execution and marks the job as Finished: FAILURE (red ball).

8. Build a Jenkins Pipeline Using a Jenkinsfile

Freestyle jobs work for quick experiments, but modern DevOps relies on Pipeline as Code. By defining your build, test, and release logic in a text file named Jenkinsfile and committing it to your Git repository, your automation pipeline is versioned, reviewed, and audited just like your application code.

Declarative vs. Scripted Pipelines

Jenkins supports two pipeline syntaxes:

Declarative Pipeline: A structured, opinionated format with clear syntax blocks (pipeline, agent, stages, steps). It is easy to read, catches configuration errors early, and is the industry-standard syntax for nearly all modern CI pipelines.
Scripted Pipeline: An older, Groovy-based programming style that offers full programmatic flexibility at the cost of higher complexity and maintenance overhead.

As a student, focus on mastering Declarative Pipelines.

Anatomy of a Jenkinsfile

Here is a practical, production-ready Jenkinsfile for our Java and Maven project:

Groovy

pipeline {
    agent any

    tools {
        // References a Maven installation configured in Global Tool Configuration
        maven 'Maven-3.9'
        // References a JDK installation configured in Global Tool Configuration
        jdk 'JDK-17'
    }

    options {
        // Automatically stop the build if it takes longer than 20 minutes
        timeout(time: 20, unit: 'MINUTES')
        // Print timestamps in the console output for easier debugging
        timestamps()
    }

    stages {
        stage('Checkout') {
            steps {
                echo 'Checking out source code from Git repository...'
                checkout scm
            }
        }

        stage('Compile & Package') {
            steps {
                echo 'Compiling source files and packaging JAR...'
                // Run Maven compile while skipping tests during this initial compilation stage
                sh 'mvn clean compile'
            }
        }

        stage('Run Automated Tests') {
            steps {
                echo 'Executing automated unit tests via Maven Surefire...'
                // Executes tests and compiles the JAR artifact
                sh 'mvn test'
            }
        }

        stage('Archive Artifacts') {
            steps {
                echo 'Archiving built application packages...'
                // Package the application into a target/*.jar file
                sh 'mvn package -DskipTests=true'
                // Store the resulting binary within Jenkins build records
                archiveArtifacts artifacts: 'target/*.jar', fingerprint: true, allowEmptyArchive: false
            }
        }
    }

    post {
        always {
            echo 'Collecting test execution results...'
            // Parse JUnit XML files produced by the Maven Surefire plugin
            junit 'target/surefire-reports/*.xml'
        }
        success {
            echo 'Pipeline completed successfully! All stages and tests passed.'
        }
        failure {
            echo 'Pipeline failed! Investigate the console output and test reports above.'
        }
    }
}

Explaining the Pipeline Sections

pipeline: The root container that tells Jenkins to parse the block as a Declarative Pipeline.
agent any: Tells Jenkins to run this pipeline on any available executor node or agent.
tools: Informs Jenkins which pre-configured compilers or build tools to automatically inject into the operating system PATH for this build.
stages: Houses the sequence of tasks that describe your software delivery lifecycle.
stage('Name'): A distinct logical segment of the pipeline. In the Jenkins UI, each stage renders as an independent column, showing you exactly how long each phase took and whether it succeeded or failed.
steps: The actual commands executed within a stage (such as running shell commands with sh, or batch scripts with bat).
post: Executes steps conditionally after all stages finish:
- always: Runs regardless of the build outcome (ideal for collecting test reports or cleaning temporary directories).
- success: Runs only if every stage finished without error.
- failure: Runs if any stage or test suite threw an error (ideal for sending alerts).

Setting Up the Pipeline Job in Jenkins

On the Jenkins home screen, click New Item.
Enter the name calculator-ci-pipeline, select Pipeline, and click OK.
Under the Pipeline configuration tab at the bottom:
- Change Definition to Pipeline script from SCM.
- Under SCM, select Git.
- Enter your Repository URL (e.g., your GitHub repository URL).
- Under Branches to build, specify */main.
- Under Script Path, ensure it reads Jenkinsfile.
Click Save.
Click Build Now. Jenkins will clone your Git repository, locate the Jenkinsfile in the project root, parse its instructions, and execute each stage.

9. Automating Tests with Jenkins

Automated testing is the primary safety net of Continuous Integration. Without testing, a CI pipeline is just an automated compiler that packages broken code faster.

How Maven and Surefire Produce Test Data

When Jenkins runs the command mvn test, the Maven lifecycle invokes the Maven Surefire Plugin. Surefire discovers all test classes ending in Test or TestCase under src/test/java, runs each test method, and writes the results to standardized XML files in the target/surefire-reports/ directory:

Plaintext

target/surefire-reports/
├── TEST-com.devopsschool.CalculatorTest.xml
└── com.devopsschool.CalculatorTest.txt

Inside TEST-com.devopsschool.CalculatorTest.xml, Surefire writes structured data detailing the execution:

XML

<?xml version="1.0" encoding="UTF-8"?>
<testsuite name="com.devopsschool.CalculatorTest" tests="3" skipped="0" failures="0" errors="0" time="0.045">
  <testcase name="testAdd()" classname="com.devopsschool.CalculatorTest" time="0.021"/>
  <testcase name="testSubtract()" classname="com.devopsschool.CalculatorTest" time="0.003"/>
  <testcase name="testDivideByZero()" classname="com.devopsschool.CalculatorTest" time="0.004"/>
</testsuite>

Publishing Test Results in Jenkins

The post block in our Jenkinsfile includes this instruction:

Groovy

junit 'target/surefire-reports/*.xml'

This step uses the Jenkins JUnit plugin to parse the XML output files. Instead of requiring developers to dig through thousands of lines of terminal logs to find why a build failed, Jenkins generates an interactive graphical Test Result dashboard directly on the job’s page.

The dashboard displays:

Total Tests Executed: The total number of individual assertions evaluated.
Failures and Errors: The exact test methods that failed, complete with stack traces, expected vs. actual values, and code line numbers.
Test Duration: How long individual tests took to complete, helping you spot performance regressions.
Test Trends: An interactive historical graph charting passing, failing, and skipped tests over time across all builds.

What Happens When a Test Fails?

To see this in action, imagine a developer changes the add method in Calculator.java to an incorrect implementation:

Java

public int add(int a, int b) {
    return a + b + 1; // Intentional logic bug
}

When this change is pushed to Git and Jenkins executes mvn test:

Plaintext

[INFO] Running com.devopsschool.CalculatorTest
[ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.052 s <<< FAILURE! -- in com.devopsschool.CalculatorTest
[ERROR] com.devopsschool.CalculatorTest.testAdd -- Time elapsed: 0.022 s <<< FAILURE!
org.opentest4j.AssertionFailedError: 10 + 5 should equal 15 ==> expected: <15> but was: <16>
	at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
	at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
	at com.devopsschool.CalculatorTest.testAdd(CalculatorTest.java:21)

Maven detects an assertion failure and exits with status code 1.
Jenkins notices the non-zero exit code and halts pipeline execution before reaching the Archive Artifacts stage. This prevents a broken application package from ever being created.
The post block activates, executing the junit step, which captures the failure details from the Surefire XML report.
The build is marked as UNSTABLE or FAILED (Red).
The Jenkins UI highlights the exact failure: com.devopsschool.CalculatorTest.testAdd - expected <15> but was <16>.

10. Triggering Builds Automatically

Manually clicking Build Now is helpful while writing and testing your pipeline, but true Continuous Integration requires builds to run automatically whenever code changes.

+------------------+         Git Push          +---------------------+
| Student commits  | ------------------------> | GitHub Repository   |
| code on laptop   |                           +---------------------+
+------------------+                                      |
                                             Webhook HTTP POST request
                                                          v
                                               +---------------------+
                                               | Jenkins Controller  |
                                               | (Starts Pipeline)   |
                                               +---------------------+

Jenkins supports several build triggers:

1. Webhooks (Industry Best Practice)

A Webhook is an automated HTTP POST payload sent from your Git host (such as GitHub or GitLab) to Jenkins whenever an event occurs—such as a developer pushing a commit or opening a pull request.

How it works: When you push code, GitHub immediately calls http://<your-jenkins-ip>:8080/github-webhook/. Jenkins receives the notification, determines which job monitors that repository and branch, and starts the build immediately.
Network Requirement: The Git host must be able to reach your Jenkins server over the network. If you are running Jenkins locally on localhost behind a home router, GitHub cannot reach it directly without an HTTP tunnel (such as ngrok) or a public IP address.

2. Polling SCM (Beginner Fallback)

If your Jenkins installation is running on a local private network or laptop without public internet ingress, you can use Poll SCM.

How it works: Jenkins periodically checks your remote Git repository on a schedule (defined using Cron syntax) to see if any new commits have appeared. If new commits exist, Jenkins triggers a build; if not, it does nothing.
Configuration: Inside your Jenkinsfile, add a triggers block:

Groovy

pipeline {
    agent any
    triggers {
        // Poll the Git repository every 15 minutes for changes
        pollSCM('H/15 * * * *')
    }
    // ... stages continue below
}

The H symbol stands for “Hash” and spreads out the polling load across your Jenkins controller to avoid sudden spikes in activity.

3. Scheduled Builds

Some builds do not need to run on every commit. For example, long-running end-to-end test suites or performance benchmarks can be scheduled to run during off-peak hours:

Groovy

triggers {
    // Run every night at midnight
    cron('H 0 * * *')
}

11. Understanding Build Failures and Troubleshooting

Encountering errors is an unavoidable part of engineering. Knowing how to diagnose and resolve build failures will save you hours of frustration.

Here is a quick-reference troubleshooting matrix for common beginner issues:

Symptom / Error Message	Root Cause	Where to Look	Practical Fix
`mvn: command not found` or `java: not found`	The tool is not installed, or its executable directory is missing from the system `PATH`.	Console Output & System Configuration	Configure the tool in Manage Jenkins > Tools, or use the `tools` directive in your `Jenkinsfile`.
`Fatal: Authentication failed for 'https://...'`	Jenkins lacks valid credentials to access a private Git repository.	Job Configuration & Credentials Vault	Add an SSH key or Personal Access Token in Manage Jenkins > Credentials, and link it to the SCM configuration.
`Non-resolvable parent POM` or `Could not resolve dependencies`	Maven cannot reach the internet to download dependencies, or repository proxy settings are incorrect.	Console Output (`mvn` logs)	Verify your network connection, inspect DNS inside your Docker container, or configure Maven’s `settings.xml` file with proper proxy settings.
`Compilation failure: [ERROR] cannot find symbol`	Syntax error, missing import, or a Java language version mismatch.	Console Output (Compiler section)	Check that your local JDK version matches the compiler target defined in `pom.xml` and Jenkins tool settings.
`FAILURE: There are test failures`	One or more unit tests failed their assertions.	Test Result tab on the Build page	Click into the failed test in the Jenkins UI to view the stack trace and pinpoint the logic error in your code.
`Recording test results... No test report files were found`	The path specified in the `junit` step does not match where Maven generated the XML reports.	Pipeline `post` block & Workspace filesystem	Confirm that the pattern `target/surefire-reports/*.xml` matches your project layout. Ensure the test stage actually ran.
`Permission denied` when creating directories	The user account running Jenkins (`jenkins`) does not own the workspace folder on the host machine.	Controller host file permissions	Run `chown -R jenkins:jenkins /var/jenkins_home` on the host machine hosting your storage volumes.

12. Jenkins Best Practices for Students

Following these simple best practices will keep your pipelines reliable, readable, and easy to maintain:

1. Treat Pipelines as Code

Always define your build instructions in a version-controlled Jenkinsfile rather than using the Jenkins UI to configure Freestyle jobs. Your pipeline definitions should be reviewed, tested, and tracked in version control right alongside your application code.

2. Never Hardcode Secrets

Never commit passwords, database credentials, API tokens, or private keys directly into a repository or Jenkinsfile. Use Jenkins’ built-in Credentials Provider and access secrets securely within your pipeline:

Groovy

environment {
    API_KEY = credentials('my-secret-api-token')
}

3. Fail Fast

Order your pipeline stages logically. Run fast, lightweight tasks first (such as static linting, compilation, and unit tests) before triggering slower, resource-intensive operations (such as end-to-end UI tests or container builds). If a simple unit test fails, there is no reason to spend twenty minutes building a Docker image.

4. Keep Build Environments Clean and Disposable

Avoid manually installing software packages inside an active build workspace. Rely on versioned tools, package managers, or containerized execution nodes. If an agent machine is destroyed, your pipeline should run smoothly on a brand-new agent without manual intervention.

5. Keep Test Suites Deterministic

Flaky tests—tests that pass on one run and fail on the next without any code changes—erode trust in your CI/CD pipeline. Tests should be isolated, avoid external network dependencies, clean up after themselves, and produce predictable results every time.

13. Extending the Pipeline Beyond Builds and Tests

Once your basic build-and-test pipeline is running smoothly, you can expand it with additional automated checks used in professional software delivery.

+-----------+   +----------+   +----------+   +---------------+   +------------+
|  Compile  |-->|   Unit   |-->| Quality  |-->| Build & Push  |-->| Deploy to  |
|  Package  |   |  Tests   |   | Analysis |   | Docker Image  |   | Staging VM |
+-----------+   +----------+   +----------+   +---------------+   +------------+

1. Static Code Analysis and Quality Gates

Integrate tools like SonarQube or SpotBugs to inspect your source code for bugs, anti-patterns, and vulnerabilities without running it. You can define a Quality Gate that halts the pipeline if code coverage drops below an agreed threshold (e.g., 80%).

2. Dependency Vulnerability Scanning

Use security plugins such as OWASP Dependency-Check or Snyk to scan your project dependencies (pom.xml) against national vulnerability databases, alerting you to known security vulnerabilities in third-party libraries.

3. Containerization with Docker

Extend your pipeline to package your application into an immutable Docker image and publish it to an artifact registry such as Docker Hub:

Groovy

stage('Build Docker Image') {
    steps {
        script {
            dockerImage = docker.build("myusername/simple-java-app:${env.BUILD_NUMBER}")
        }
    }
}

4. Automated Deployment

Add a deployment stage that transfers your packaged artifacts to a cloud server, testing environment, or staging Kubernetes cluster whenever a build on your main branch succeeds.

5. Automated Notifications

Configure the post block to send notifications to Discord, Slack, or email channels, letting your team know immediately when a build succeeds or requires attention.

14. A Mini Project: Build and Test Automation from Start to Finish

Put your new knowledge into practice with this step-by-step hands-on exercise.

       PROJECT ROADMAP
Step 1: Write Java code & JUnit tests
                 |
Step 2: Commit & push to your Git repo
                 |
Step 3: Point Jenkins to your repository
                 |
Step 4: Run the pipeline & see Green
                 |
Step 5: Introduce an intentional bug
                 |
Step 6: Watch Jenkins catch the failure
                 |
Step 7: Fix the bug & restore to Green

Step 1: Create the Project

Create a new directory named student-ci-demo containing the pom.xml, Calculator.java, and CalculatorTest.java files detailed in Section 6.

Step 2: Add the Jenkinsfile

Create a file named Jenkinsfile in the root of your project directory using the Declarative Pipeline code from Section 8.

Step 3: Push to Git

Initialize Git, commit your project files, create a new repository on your preferred Git host, and push your commits to the main branch:

Bash

git init
git add .
git commit -m "feat: complete initial project setup with pipeline"
git branch -M main
git remote add origin <your-git-repo-url>
git push -u origin main

Step 4: Configure Jenkins

Open Jenkins at http://localhost:8080.
Click New Item, choose Pipeline, and name it student-mini-project.
In the configuration under Pipeline, set Definition to Pipeline script from SCM.
Set SCM to Git, provide your repository URL, and set the branch to */main.
Click Save, then click Build Now.

Step 5: Verify the Passing Build

Watch the Stage View dashboard. The stages—Checkout, Compile & Package, Run Automated Tests, and Archive Artifacts—will turn green one by one.
Click into the build, select Test Result, and confirm that 3 tests ran with 0 failures.

Step 6: Break a Test Intentionally

Simulate a developer error. Open Calculator.java and modify the subtract method:

Java

public int subtract(int a, int b) {
    return a - b - 10; // Intentional defect
}

Commit and push this change to your repository:

Bash

git commit -am "refactor: tweak subtraction logic"
git push origin main

Step 7: Observe the Failure

Return to Jenkins and click Build Now (or wait for your webhook or polling trigger to run).
The pipeline will stop at the Run Automated Tests stage, turning Red.
Click the failed build number, open the Test Result page, and review the error:PlaintextCalculatorTest.testSubtract: expected: <5> but was: <-5>
Notice that the Archive Artifacts stage was skipped completely, preventing a broken application binary from being created.

Step 8: Fix and Verify

Correct the calculation in Calculator.java, commit the fix, and push it to Git. Run the pipeline one more time to see your pipeline return to a clean, passing Green state.

15. Frequently Asked Questions (FAQ)

What is Jenkins used for?

Jenkins is an open-source automation server used primarily to implement Continuous Integration (CI) and Continuous Delivery (CD). It automates repetitive tasks throughout the software lifecycle, including code checkout, compilation, unit and integration testing, code analysis, packaging, and deployment to hosting environments.

Is Jenkins suitable for beginners?

Yes. While Jenkins offers powerful features for enterprise use, its core concepts—automating builds, running commands, and displaying test results—are straightforward to learn. Starting with a basic Declarative Pipeline on a single project is an approachable, hands-on way for students to learn CI/CD fundamentals.

What is the difference between a Jenkins job and a Jenkins pipeline?

A Jenkins job is a broad term for any automated task configured in Jenkins, historically set up via the graphical UI (such as a Freestyle job). A Jenkins pipeline is a modern, code-based workflow that models your entire build, test, and release process as code using a Jenkinsfile, which can be checked into version control alongside your project.

What is a Jenkinsfile?

A Jenkinsfile is a text configuration file stored in the root of your source code repository that defines your Jenkins pipeline. Written using Declarative or Scripted pipeline syntax, it models the build, test, and deployment stages as code, ensuring your automation workflow is versioned and tracked alongside your application code.

How does Jenkins automate software testing?

Jenkins executes test commands through build tools or test runners (such as mvn test for Java, npm test for JavaScript, or pytest for Python). Jenkins captures the test results, parses generated XML report files (like JUnit XML), marks builds as passed or failed based on test outcomes, and generates visual trend reports on the dashboard.

Does Jenkins require Java?

Yes. The Jenkins controller itself is written in Java and requires a supported Java runtime (typically OpenJDK 17 or 21) to execute. However, this does not limit what Jenkins can build; it can build and test software written in any programming language.

Can Jenkins build applications written in different programming languages?

Yes. Jenkins is language-agnostic. By installing the relevant tools, compilers, and plugins—or by running build steps inside Docker containers—Jenkins can automate projects written in Python, Node.js, Go, C++, C#, Rust, Ruby, or any other programming language.

What happens when a Jenkins test fails?

When an automated test fails, the test runner exits with a non-zero exit status. Jenkins detects this exit code, halts the pipeline to prevent broken code from advancing to packaging or deployment, flags the build as Failed (Red) or Unstable (Yellow), highlights the failing assertions on the dashboard, and notifies the team.

Is Jenkins free to use?

Yes. Jenkins is open-source software released under the MIT License. It is completely free to download, install, modify, and use for personal, academic, or commercial projects.

What should students learn after creating their first Jenkins pipeline?

After mastering basic build and test automation, students should explore:

Running build agents dynamically inside Docker containers.
Static code analysis and security auditing with SonarQube.
Managing pull requests automatically using GitHub/GitLab webhooks.
Deploying applications to cloud infrastructure or container orchestration platforms like Kubernetes.

16. Conclusion

Mastering Jenkins transforms software development from an error-prone manual chore into a reliable, professional engineering discipline. By learning how to configure declarative pipelines, automate builds with Maven, and let automated test suites catch regressions early, students gain direct experience with the continuous integration workflows used across top tech teams. Building confidence in DevOps starts with these small, consistent experiments—setting up a local server, intentionally breaking tests to learn how Jenkins handles failure, and gradually extending your pipeline with new tools. As you integrate automation into your academic assignments and personal projects, you not only eliminate late-night integration headaches but also develop the practical, job-ready CI/CD skills essential for a successful career in software delivery.

Amelia Olivia

1. Introduction

2. What Is Jenkins?

Manual vs. Automated Builds

How Jenkins Supports CI/CD

The Role of an Orchestrator

3. Understanding Builds, Automated Tests, and CI

What Is a Software Build?

The Testing Pyramid

The Cost of Build and Test Failures

4. How Jenkins Works: Architecture and Core Components

Core Components

5. Setting Up Jenkins for Learning

System Requirements

Setup Methods: Native vs. Docker

Method A: Running Jenkins via Docker

Method B: Native Installation on Ubuntu/Debian Linux

Initial Administrator Setup

6. Prepare a Sample Application for Automation

Standard Maven Project Directory Structure

1. The Build Configuration (pom.xml)

2. The Application Code (Calculator.java)

3. The Unit Test Suite (CalculatorTest.java)

7. Create Your First Jenkins Job

Freestyle Jobs vs. Pipeline Jobs

Exploring a Basic Freestyle Build (Walkthrough)

Running the Job and Inspecting Output

8. Build a Jenkins Pipeline Using a Jenkinsfile

Declarative vs. Scripted Pipelines

Anatomy of a Jenkinsfile

Explaining the Pipeline Sections

Setting Up the Pipeline Job in Jenkins

9. Automating Tests with Jenkins

How Maven and Surefire Produce Test Data

Publishing Test Results in Jenkins

What Happens When a Test Fails?

10. Triggering Builds Automatically

1. Webhooks (Industry Best Practice)

2. Polling SCM (Beginner Fallback)

3. Scheduled Builds

11. Understanding Build Failures and Troubleshooting

12. Jenkins Best Practices for Students

1. Treat Pipelines as Code

2. Never Hardcode Secrets

3. Fail Fast

4. Keep Build Environments Clean and Disposable

5. Keep Test Suites Deterministic

13. Extending the Pipeline Beyond Builds and Tests

1. Static Code Analysis and Quality Gates

2. Dependency Vulnerability Scanning

3. Containerization with Docker

4. Automated Deployment

5. Automated Notifications

14. A Mini Project: Build and Test Automation from Start to Finish

Step 1: Create the Project

Step 2: Add the Jenkinsfile

Step 3: Push to Git

Step 4: Configure Jenkins

Step 5: Verify the Passing Build

Step 6: Break a Test Intentionally

Step 7: Observe the Failure

Step 8: Fix and Verify

15. Frequently Asked Questions (FAQ)

What is Jenkins used for?

Is Jenkins suitable for beginners?

What is the difference between a Jenkins job and a Jenkins pipeline?

What is a Jenkinsfile?

How does Jenkins automate software testing?

Does Jenkins require Java?

Can Jenkins build applications written in different programming languages?

What happens when a Jenkins test fails?

Is Jenkins free to use?

What should students learn after creating their first Jenkins pipeline?

16. Conclusion

1. The Build Configuration (`pom.xml`)

2. The Application Code (`Calculator.java`)

3. The Unit Test Suite (`CalculatorTest.java`)