Build Triggers & Webhooks

A pipeline sitting in a Jenkinsfile does nothing until something tells Jenkins to run it. There are three common ways that happens.

1. Webhooks (push-triggered)

Your git host (GitHub, GitLab, Bitbucket) calls a URL on your Jenkins controller the instant someone pushes a commit. Jenkins starts the build within seconds, with zero delay and zero wasted checks when nothing has changed.

This is the gold standard for responsiveness, but it requires your Jenkins controller to be reachable from the internet (or at least from your git host) - not always true for a controller sitting deep inside a private network.

2. Polling SCM

If a webhook isn't possible, Jenkins can instead check the repository on a schedule - "every 5 minutes, has anything changed? If so, build." It's less instant and wastes a small amount of work on every check that finds nothing new, but it works from anywhere Jenkins can reach the repo, no inbound connection required.

3. Scheduled builds (cron syntax)

Some builds don't wait on a code change at all - a nightly full-suite run, a weekly dependency-update check. These use the exact same five-field cron syntax you'd put in a real crontab:

minute hour day-of-month month day-of-week
0      1    *             *     *

Jenkins adds one twist: an H in place of a number (H 1 * * *) tells it to pick a consistent-but-spread-out minute itself, so a thousand jobs scheduled for "1 AM" don't all slam the build farm in the exact same 60 seconds.

Try it

Real cron, outside of Jenkins, works the same way - a line in a file, loaded with crontab:

echo '0 1 * * * /usr/local/bin/run-pipeline.sh' > nightly-build

When you're ready, hit Mark complete and move to the next lesson.