Triggers & webhooks

Build on push, on schedule, on demand.

A pipeline is only useful if it runs at the right moments. Jenkins offers several triggers, and the right one depends on the goal: build on every push for fast feedback, build on a schedule for nightly jobs, or build on demand for a manual deploy. Most projects use a mix, declared in the Jenkinsfile so the triggering rules are versioned with everything else.

Webhooks vs polling

Two ways to build on a push. Polling has Jenkins ask the repository every few minutes "anything new?" — simple, but wasteful and laggy. A webhook flips it: the repository (GitHub, GitLab, Bitbucket) sends Jenkins an HTTP notification the instant a push happens, so builds start immediately and Jenkins is not hammering the SCM. Webhooks are the right default; polling is the fallback when Jenkins cannot receive inbound calls.

triggers {
  // webhook is configured in the repo; this handles schedule + polling fallback
  cron('H 2 * * *')          // a nightly build (H spreads load across the hour)
  pollSCM('H/15 * * * *')    // fallback: check the repo every ~15 min if no webhook
}

The H (hash) trick

In Jenkins cron syntax, H means "hash" — pick a stable but spread-out minute rather than a fixed one. cron('H 2 * * *') runs once in the 2am hour, but at a minute derived from the job name, so a hundred nightly jobs do not all fire at exactly 2:00 and stampede the agents. Use H everywhere you would write a specific minute in a Jenkins schedule.