Jenkins Build & Deployment: Maven Integration, pom.xml & Artifacts

Jenkins Maven Integration & Deployment

Most automation suites don't run only when someone clicks Build Now. Smoke tests run on every code change, regression runs every night, and a full cross-browser run might happen once a week. Jenkins handles all of this with three kinds of triggers: Build periodically (a fixed schedule), Poll SCM (check the repository on a schedule) and webhooks (the repository tells Jenkins about a change). All three use or relate to CRON syntax, so that's where we start.

The CRON Format

A Jenkins schedule has 5 fields, separated by spaces:

MINUTE  HOUR  DAY-OF-MONTH  MONTH  DAY-OF-WEEK

Special characters: * (every value), , (a list, e.g. 1,3,5), - (a range, e.g. 1-5), / (a step, e.g. */15 = every 15), and Jenkins' own H, explained below. Lines starting with # are comments, and you can put several schedules on separate lines.

Common Schedules — With Their Next Runs

We calculated the next three runs of each expression from Monday 28 September 2026, 10:30 to show exactly what they do:

Two things are easy to miss: "Every day at 2 AM" first runs tomorrow morning, not today, and a weekday schedule simply doesn't fire on Saturday and Sunday. Jenkins also shows a preview under the schedule box ("Would last have run at … would next run at …") — check it every time you save.

The H Symbol: Why Jenkins Prefers H 2 * * *

If fifty jobs all use 0 2 * * *, they all start at exactly 02:00 and fight for the same agents, browsers and test environment. H ("hash") replaces a fixed value with one Jenkins picks from the job name — spread out across jobs but stable for each job:

• H 2 * * * — once between 02:00 and 02:59, at the same minute every night for this job.
• H/15 * * * * — every 15 minutes, but not all jobs on :00, :15, :30, :45.
• H H(0-5) * * 1-5 — once a night between midnight and 05:59 on weekdays.

Jenkins itself warns when you use a fixed minute like 0 in a frequently-running schedule and suggests H. Use a fixed time only when it genuinely matters (for example, the run must finish before a 07:00 stand-up).

Time Zones

Schedules use the Jenkins controller's time zone by default. For a server in UTC and a team in India, 0 2 * * * runs at 07:30 IST. You can set the zone per job by adding a line before the schedule:

TZ=Asia/Kolkata
H 2 * * 1-5

Build Periodically vs Poll SCM vs Webhook

The network row usually decides it: webhooks are the best option, but a Jenkins server inside a company network often can't receive calls from GitHub or GitLab, so teams fall back to Poll SCM (with H/5 * * * * or similar) until that's solved.

Setting up a GitHub webhook

1. In Jenkins, install the GitHub plugin and, in the job, tick GitHub hook trigger for GITScm polling (or use githubPush() in a Jenkinsfile).
2. In the GitHub repository: Settings → Webhooks → Add webhook.
3. Payload URL: https://your-jenkins.example.com/github-webhook/ (the trailing slash matters), content type application/json, event: Just the push event.
4. Push a small commit and check Recent Deliveries in GitHub for a green 200 response.

GitLab and Bitbucket work the same way through their own plugins and webhook URLs.

Triggers in a Jenkinsfile

pipeline {
  agent any
  triggers {
    cron('TZ=Asia/Kolkata\nH 2 * * 1-5')   // nightly regression on weekdays
    // pollSCM('H/5 * * * *')              // fallback when webhooks can't reach Jenkins
    // githubPush()                        // webhook-triggered builds (GitHub plugin)
  }
  stages {
    stage('Regression') {
      steps { sh 'mvn -B clean test -Dgroups=regression -Dheadless=true' }
    }
  }
  post {
    always { junit 'target/surefire-reports/*.xml' }
  }
}

A common setup uses two jobs from the same repository: a fast smoke job triggered by webhooks on every push, and a full regression job on a nightly CRON. Scheduled runs usually need browsers available at 2 AM without anyone logged in — which is where containers help; see the Docker + Selenium Grid Guide. Full pipeline syntax: Jenkins Pipelines & Jenkinsfile.

Troubleshooting Scheduled Builds

• Runs at the wrong hour: the controller's time zone differs from yours — add TZ=.
• Didn't run at all: the job is disabled, the controller was restarting or in quiet mode at that time, or no agent with the right label was online.
• Webhook builds never start: check the delivery status in GitHub — a 403/404 usually means a wrong URL (missing trailing slash) or authentication; a timeout means GitHub can't reach Jenkins.
• Pipeline trigger ignored: triggers in a Jenkinsfile only register after the pipeline has run once — run it manually after adding or changing them.

From Real Projects

In my projects I ran Selenium and TestNG suites in batch, group, parallel and cross-browser mode. A CI server like Jenkins is the natural next step: the same suites, triggered automatically after each build or on a schedule, with results published for the whole team. On Canolog, the many forms and screens across sales, inventory, finance and service are where keeping page details in POM classes and reusable steps in a business library paid off. Running clean install test runs the tests twice — use one goal.

📚 Official documentation: Jenkins documentation

FAQs

How do you schedule a job in Jenkins?

Use Build periodically (or triggers { cron(...) } in a Jenkinsfile) with a 5-field CRON expression such as H 2 * * 1-5.

What does H mean in Jenkins CRON?

A hash-based value Jenkins picks from the job name — it spreads jobs across the range while keeping each job's time stable.

What is the difference between Build Periodically and Poll SCM?

Build periodically always runs at the scheduled time; Poll SCM checks the repository on a schedule and builds only if something changed.

Why are webhooks better than Poll SCM?

They trigger builds seconds after a push and put no polling load on the Git server — but the Git host must be able to reach Jenkins.

Which time zone does Jenkins CRON use?

The controller's, unless you add a TZ= line before the schedule.

Related

• Jenkins Freestyle vs Pipeline Jobs
• The Complete Jenkins Tutorial