Right now you click "Build Now" to run the pipeline. That is manual. The whole point of CI is automation. You need triggers — something that starts the pipeline without human intervention. There are three ways: polling, webhooks, and cron scheduling.
| Poll SCM (Pull) | Webhook (Push) |
|---|---|
| Jenkins checks Git every X minutes | Git tells Jenkins when code is pushed |
| "Hey Git, anything new?" | "Hey Jenkins, new code just landed!" |
| Wastes resources if nothing changed | Instant trigger, no wasted checks |
| Simple to set up, no network config | Needs Jenkins accessible from internet |
| Good for: learning, internal repos | Good for: production, GitHub repos |
pipeline {
agent any
triggers {
// Check Git for changes every 5 minutes
pollSCM('H/5 * * * *')
}
stages {
// ... your stages here
}
}Every 5 minutes, Jenkins asks Git: "Any new commits since my last check?" If yes, it runs the pipeline. If no, it does nothing. Simple but wasteful — Jenkins keeps asking even when nobody is pushing code.
triggers {
// Run full regression at 2 AM on weekdays
cron('H 2 * * 1-5')
}# MINUTE HOUR DAY_OF_MONTH MONTH DAY_OF_WEEK
# 0-59 0-23 1-31 1-12 0-7 (0 and 7 = Sunday)
# H = hash — Jenkins picks a random minute to spread load
# Without H, if 50 jobs all say "0 2 * * *", they ALL start at 2:00 AM
# With H, they spread across 2:00-2:59 AM
H 2 * * 1-5 # Weekdays at ~2 AM (nightly regression)
H/15 * * * * # Every 15 minutes (aggressive polling)
H 8 * * * # Daily at ~8 AM (morning smoke)
H 22 * * 5 # Every Friday at ~10 PM (weekend regression)
H 6,18 * * 1-5 # Weekdays at ~6 AM and ~6 PM (twice daily)Always use H instead of a fixed minute. "0 2 * * *" means exactly 2:00 AM. "H 2 * * *" means sometime between 2:00 and 2:59 AM. Jenkins uses a hash of the job name to pick the exact minute, so different jobs spread out automatically.
Webhooks are the professional approach. Instead of Jenkins polling Git every 5 minutes, GitHub tells Jenkins the moment someone pushes code. Instant. No wasted resources.
Webhooks need Jenkins to be reachable from the internet. If Jenkins runs on your laptop, GitHub cannot reach it. For local testing, use ngrok (ngrok http 8080) to create a temporary public URL. For production, Jenkins runs on a server with a public IP.
triggers {
// Instant trigger on push (for smoke tests)
// This needs webhook configured in GitHub
pollSCM('')
// Nightly regression at 2 AM on weekdays
cron('H 2 * * 1-5')
}Most teams use this combination: webhook for fast smoke feedback on every push, and cron for full regression every night. The empty string in pollSCM enables webhook triggering without actual polling.
Q: How do you schedule and trigger test runs in Jenkins?
A: We use a combination of triggers. For fast feedback, GitHub webhooks trigger smoke tests on every push — results are ready in 5-10 minutes. For full regression, we use Jenkins cron to run the complete suite nightly at 2 AM on weekdays (cron: H 2 * * 1-5). The H hash distributes the load so multiple jobs do not all start at the same minute. We also have parameterized manual builds for ad-hoc runs before releases. This three-tier approach balances speed, coverage, and resource usage.
Key Point: Use webhooks for instant smoke tests on every push. Use cron for nightly regression. Combine both for a solid CI strategy.