How to automate builds with Jenkins using Jenkinsfile

Working with CI/CD pipelines has become one of my favorite parts of being involved in automation projects. A background system automatically compiles, tests, and reports results whenever I commit code. This magic is powered by Jenkins, one of the most popular open-source automation servers available today.

In this blog, I’ll walk you through how I configured a Jenkins pipeline for one of my test automation projects, dsportal-cucumber-bdd-test-automation. I used a Jenkinsfile, where the pipeline steps are written as code to automate the build and test process.

Pipeline as Code

Pipeline as code (PaC) describes a set of features that allow Jenkins users to define pipeline scripts with code. This code is written in a Jenkinsfile and stored and versioned in a source repository. With this, Jenkins can discover, manage, and run jobs automatically.

Let us see how I configured a Jenkinsfile pipeline for my project.

Step 1: Create a Jenkinsfile

Create a file called Jenkinsfile in the root of your GitHub repository. The file should be named exactly as "Jenkinsfile" without any extensions. The pipeline steps will be written in this file.

Jenkinsfile in the root directory of the repository

Step 2: Write pipeline steps inside the Jenkinsfile

Once the Jenkinsfile is created, we write the pipeline steps in this file. The pipeline steps are written as declarative pipeline syntax.

Declarative Pipelines contains these blocks:

1. pipeline block: The root block that contains everything.

2. agent block: Defines where the pipeline will run (e.g., on any available node or a specific node).

3. tools block: Optional, defines the tools needed for the build.

4. stages block: Groups the pipeline's stages (like checkout, build, test, etc.).

5. steps block: Defines the actual steps in each stage.

6. post block:  Defines actions to be executed after the pipeline finishes.

Here’s the screenshot of the Jenkinsfile from my project:

Pipeline steps in Jenkinsfile

Let’s break down what the above Jenkinsfile does:

1. Runs on any available Jenkins agent 

2. Sets up required tools:

   • Maven (for building the project)

   • JDK (Java runtime)

   • Allure (for test reporting)

   Note: The names like 'Maven_Home', 'my JDK', and 'allure' must match the tool names you’ve configured under Manage Jenkins → Global Tool Configuration.

3. Check out the project code from your GitHub repository.

4. Runs a Maven clean compile to clean and compile the application.

5. Runs automated tests using mvn test.

6. Handles test failures gracefully using catchError

7. Archives build artifacts for download.

8. Generates an Allure report using test results.

   
   

Once the Jenkinsfile is ready, the next step is to create a Jenkins Pipeline job.

Step 3: Create a Jenkins Pipeline

In this step, you tell Jenkins where to find your Jenkinsfile so it knows what steps to run. Below are the steps to create a Jenkins Pipeline:

1. Go to the Jenkins dashboard and click New Item.

2. Enter a name for the job and select “Pipeline” as the project type.

3. In the Pipeline Configuration, under the Pipeline script from the SCM section:

   1. Choose Git as the SCM.

   2. Paste the GitHub repository URL.

   3. Set the branch name

   4. Jenkins will automatically look for a file named Jenkinsfile in the repository's root.

Once saved, Jenkins will be ready to execute the pipeline using the steps defined in that Jenkinsfile.

Pipeline configuration - setting the Repository URL

Pipeline Configuration - Script Path

Step 4: Set Up the Trigger

Triggers decide when the Jenkins pipeline runs. Typically, you want it to kick off automatically whenever someone pushes code to your repository. Jenkins supports multiple ways to configure automated triggers.

In my test automation project, I set up automated triggering using Git polling. This is a simple and effective option, especially for local Jenkins setups that aren't exposed to the internet. If you're using a public Jenkins instance, a more efficient option would be GitHub webhooks.

Note: GitHub webhooks offer a more efficient way to trigger pipelines for publicly accessible Jenkins servers. However, this blog focuses on Git polling, which works best for local Jenkins setups.

Setting up Git polling is simple. Jenkins checks GitHub every few minutes for code changes, making it perfect for local Jenkins environments where you don’t have a public URL for GitHub to notify.

To enable Git Polling, follow these steps:

1. Go to your Jenkins pipeline job.

2. Under Triggers → Check Poll SCM.

3. Use a schedule to poll every 5 minutes.

Pipeline configuration - setting triggers

Step 5: Make Changes to Code

Now that the pipeline setup is complete, it’s time to execute it. Make small changes to your project. It can be a simple change like updating a comment. Then, push your changes to GitHub by committing the update.

If your trigger is configured correctly (Git polling every 5 minutes), Jenkins will detect the change and automatically start the pipeline.

That's it. Let's see the Jenkins Pipeline in Action now.

Jenkins Pipeline in Action

Once your Jenkins pipeline is triggered, you'll see it move through the stages you defined in your Jenkinsfile. This includes steps like checkout, tool install, build, and test execution — all happening automatically. You can monitor progress directly in Jenkins under Stages.

The screenshot below shows the pipeline stages for builds 1 to 5. In builds 1 to 3, the "Build" stage failed — as a result, the "Run Tests" stage was skipped altogether. However, the "Post Actions" stage was configured to run always, regardless of the build outcome.

This issue was corrected in builds 4 and 5. The "Build" stage was completed successfully, allowing the "Run Tests" stage to execute. In "Run Tests", some test failures occurred, which was expected for my project. Because of this, the "Run Tests" stage is marked with a warning (!) symbol in the pipeline.

The visual pipeline view makes it easy to spot where failures happen, so corrective actions can be taken quickly.

Jenkins Pipeline Stages

Git Polling Log

We have configured the polling schedule as 5 minutes. So, every 5 minutes, Jenkins checks Git for new commits. If there are no new commits, it does nothing. If there are new commits, Jenkins triggers a build automatically. One thing to note is that polling doesn't create a heavy load on GitHub. It only performs a metadata check, which is a lightweight operation. Jenkins only clones the GitHub repository when changes are found.

Here's a screenshot of the Jenkins Git polling log showing how it detected changes and decided to run the pipeline.

Git polling log

Pipeline Execution Steps

As an example, let's see the pipeline for build #5.

You can see each stage running in sequence:

• Checkout SCM: Jenkins checks out the project from the GitHub repository.

• Tool Install: Jenkins sets up the tools defined in the tools block — Maven, JDK, and Allure.

• Checkout: Re-checkout of the code as part of the pipeline's first stage.

• Build: Maven runs clean compile to build the project.

• Run Tests: Executes automated tests using mvn test. Run Tests finished with errors because of test failures, which is expected in this project setup.

• Post Actions: Archives artifacts and generates the Allure report.

Pipeline Console for Build #5

I hope this blog was helpful to you in getting started with Jenkinsfile. Using a Jenkinsfile, the entire CI/CD pipeline can be version-controlled. This allows every change to be tracked and tested just like application code. You will save a lot of time and effort when using Jenkinsfile compared to implementing complex CI/CD workflows through UIs and web forms.

Automation is powerful, but only when applied thoughtfully. As Bill Gates once said:

"The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency." — Bill Gates.