Why this exists

If you have ever watched a build pass on your laptop and then melt down in CI, welcome to the club. This guide shows how to make Jenkins run Maven builds inside Docker so results stop depending on which developer fed the build server last. It is about reproducible CI, predictable build automation, and fewer blame games in your DevOps standups.

Quick checklist before you start

• Install Docker on the machine that runs your Jenkins agents
• Install the Jenkins Docker plugin and restart Jenkins if needed
• Give the Jenkins user permission to talk to Docker so builds do not fail for boring permission reasons
• Decide how to cache Maven dependencies to keep build times reasonable

Why grant Docker access to Jenkins

Running the pipeline is not a magic spell. Jenkins needs permission to create and remove containers. If Docker commands fail you will waste time debugging the build instead of fixing the code that actually broke.

Minimal Jenkinsfile that keeps things simple

Here is a compact declarative Jenkinsfile that runs Maven inside a Docker agent. It uses a standard Maven image to keep the environment consistent across runs.

pipeline {
  agent { docker { image 'maven 3 jdk 8' } }
  stages {
    stage('Checkout') {
      steps {
        checkout scm
      }
    }
    stage('Build') {
      steps {
        sh 'mvn -B clean package'
      }
    }
    stage('Publish Test Results') {
      steps {
        junit 'target/surefire-reports/*.xml'
      }
    }
  }
  post {
    always {
      cleanWs()
    }
  }
}

Notes about the snippet above, because I know you will ask. Using the Maven image ensures the same JDK and Maven version across CI runs. The checkout step uses the repository configured for the job. The junit step gives you nice test reports in the Jenkins UI instead of making you squint through console logs.

Archive artifacts and keep history

After the build produces JARs or WARs, use the archive artifacts feature in the pipeline or the UI to store binary outputs. This provides a quick way to download artifacts from past builds and it fingerprints files so you can trace which commit produced which binary. If you prefer a code example for archiving you can add the archiveArtifacts step in the pipeline configuration.

Speed up builds with Maven caching

Maven downloads a lot of jars. Let it cache them so your CI does not cry every morning. You can mount a persistent volume for the Maven local repository or use a host directory mount. The exact method depends on your Jenkins agent setup, whether you run agents as containers or on VMs, and how much disk you want to sacrifice to speed.

• If you use Docker agents, persist the Maven cache across containers to avoid repeated downloads
• If you run agents on VMs, store .m2 at a shared path that agents can access
• Consider a repository manager like Nexus or Artifactory if you want to be fancy and not depend on the internet

Test failures and cleanup

Fail fast on broken tests. Use the junit publisher so test failures become clear pipeline failures and not a cryptic exit code. Also make cleanup a habit. Remove temporary containers and workspace files to avoid flaky runs and disk exhaustion. The cleanWs step in the post block is your friend unless you enjoy manual cleanup jobs.

Summary and recommended next steps

In short, use a Jenkinsfile with a Docker agent to run Maven builds for consistent CI. Make sure Docker is installed and accessible to Jenkins, cache Maven dependencies to speed builds, publish test reports with the junit step, and archive artifacts for traceability. This pattern brings order to your build automation, reduces surprises in continuous integration, and keeps your DevOps life slightly less chaotic.