(Day 19) Task : Automating Java Builds with Jenkins and Maven :-

In this article of the Jenkins and Maven DevOps series, we dive into three powerful features that make Jenkins essential for modern software development: Maven build jobs, task scheduling, and Source Code Management (SCM) polling.

Whether you're a student learning DevOps, preparing for interviews, or building real-world CI/CD pipelines, this article is packed with practical steps and demonstrations.

1. Setting Up Maven Jobs in Jenkins :

Jenkins supports Apache Maven, a powerful tool for managing Java projects. Here’s how you configure and use it inside Jenkins:

Maven Configuration in Jenkins :

• Go to Manage Jenkins > Global Tool Configuration.

• Under Maven, click Add Maven.

• Provide:

  • A name (e.g., Maven-3.8.8).

  • Optionally let Jenkins install it automatically or provide the installation path.

• This configuration is reused in Maven jobs.

Creating a Maven Job :

• From the Jenkins dashboard:

  • Click New Item

  • Enter job name and select Maven Project

• Inside the job:

  • Source Code Management: Choose Git and provide the repository URL.

  • Set your POM file path if it’s in a subdirectory (default is pom.xml).

  • Add Maven goals:

    • Example: clean install (cleans old files and builds fresh).

  • Save and build.

Benefits :

• Automates the compilation, packaging, and testing of Java code.

• Replaces the need to run builds manually.

• Integrates well with CI/CD workflows.

2. Scheduling Tasks in Jenkins :

One of Jenkins' most powerful features is its ability to automatically schedule jobs. This means you can define when and how often a job (such as a build, test, or deployment) should run — without manual intervention. This is crucial for automated CI/CD pipelines, where regular feedback is necessary for development efficiency.

What is Job Scheduling in Jenkins?

Scheduling in Jenkins allows you to trigger a job at fixed times or regular intervals, such as:

• Running builds every hour.

• Executing test cases every night.

• Compiling reports every Monday morning.

This is particularly useful when you want to ensure consistency in testing or when builds are needed at predictable times — even if the code hasn't changed.

How to Enable Scheduling in Jenkins

To schedule a task in Jenkins, follow these steps:

1. Create or Open a Jenkins Job :

   • Navigate to your Jenkins dashboard.

   • Click on an existing job or create a new one.

2. Go to Job Configuration :

   • Click on “Configure” on the left sidebar of the job.

3. Find the Build Triggers Section :

   • Scroll to the "Build Triggers" section.

4. Enable 'Build Periodically' :

   • Check the box labeled “Build periodically”.

   • A textbox will appear where you can enter the CRON schedule expression.

Examples:

• @daily – Run once a day at midnight

• H 0 * * * – Run every day at 12:00 AM

• H/15 * * * * – Run every 15 minutes

• 0 9 * * 1-5 – Run at 9 AM, Monday to Friday

• 0 12 1 * * – Run at noon on the 1st of every month

• Note: The H (Hash) symbol in Jenkins distributes load evenly across time, so not all jobs run at exactly the same time.

When to Use Build Scheduling?

Scheduling is useful when you want jobs to run even without any change in the source code. Typical use cases:

• Nightly Builds: Run all tests and compile reports every night at 2 AM.

• Weekly Report Jobs: Generate analytics or code coverage reports every Monday morning.

• Uptime Checks: Run health checks on your application endpoints every 30 minutes.

3. Source Code Polling in Jenkins :

One of the most efficient and intelligent ways to automate builds in Jenkins is by using Source Code Polling. Unlike time-based job scheduling, polling allows Jenkins to monitor your code repository and trigger jobs only when there are actual changes. This is an essential practice in modern CI/CD pipelines, enabling fast feedback loops and reduced manual overhead.

What is Source Code Polling in Jenkins?

Source Code Polling is a Jenkins feature that regularly checks a version control system (like Git) to see if new commits or changes have been made. If it detects a change, it automatically triggers a build.

Think of it like this:

“Instead of building every 30 minutes (even if nothing changed), only build when the code actually changes.” This makes the pipeline more responsive, efficient, and cost-effective, especially for large teams and frequent deployments.

How Source Code Polling Works

1. Jenkins periodically checks the configured Source Code Management (SCM) tool (e.g., GitHub, GitLab, Bitbucket).

2. It compares the latest commit hash in the remote branch with the last successful build’s hash.

3. If the hashes are different (indicating code changes), Jenkins triggers a build.

4. If there are no changes, it skips the build and waits until the next poll.

This keeps your pipeline optimised and avoids unnecessary builds.

Setting Up Source Code Polling in Jenkins (Step-by-Step)

Here’s how to enable polling in a Jenkins job:

Open or Create a Job :

• Navigate to the Jenkins dashboard.

• Select an existing job or click "New Item" to create one.

Configure the SCM :

• In the job configuration, scroll to Source Code Management.

• Select Git (or another VCS like Subversion).

• Provide:

  • Repository URL

  • Branch to build (e.g., */main or */dev)

  • Git credentials (if it's a private repo)

Enable Polling :

• Scroll down to Build Triggers.

• Check the box labeled “Poll SCM”.

• Enter the polling schedule using CRON syntax. Example:

    H/5 * * * *
  

  → This checks the repository for changes every 5 minutes.

Save and Run

• Save the configuration.

• Jenkins will now poll the repository at the defined intervals and trigger builds if changes are detected.

Understanding CRON Syntax for Polling :

Example: H/15 * * * * → Polls every 15 minutes
Example: H 0 * * * → Polls daily at midnight

The H symbol stands for "hashed" — Jenkins distributes polling across time to prevent all jobs from polling simultaneously.

Why Use Source Code Polling?

Pros

• Efficient: Only triggers builds when necessary.

• Responsive: Builds happen soon after a developer pushes code.

• Reduces Resource Wastage: Prevents unnecessary builds when there are no changes.

• Improves CI Feedback: Developers get quick feedback on their commits.

Cons

• Still consumes resources to poll periodically, even if there's no change.

• May cause slight delay (up to the polling interval) in detecting changes.

• Not as immediate as web-hooks (push-based triggers).