Webhooks, Poll SCM, Cron, and Build Causes

Scenario: Hundreds of jobs poll each minute, loading SCM while still delivering delayed feedback.

Pipeline example

pipeline { agent any; triggers { pollSCM('H/15 * * * *'); cron('H 2 * * *') }; stages { stage('Cause') { steps { echo 'inspect cause' } } } }

Push, poll, and schedule have different contracts

Webhooks deliver low-latency SCM events and should carry a validated provider signature. Poll SCM asks whether relevant source changed and builds only when it did. Cron schedules a run regardless of source changes. Jenkins hash syntax H assigns stable offsets, spreading jobs instead of creating a midnight or top-of-hour surge. Hundreds of one-minute polls waste repository API capacity while still delaying feedback.

Webhooks can be lost during maintenance, so a lower-frequency scan can reconcile missed changes. Avoid enabling several trigger paths that build the same revision twice unless deduplication and concurrency are explicit. A timer-driven maintenance build must record the revision it selected rather than implicitly deploying whichever head exists later.

Causes form audit evidence

Jenkins attaches user, timer, SCM, upstream, and remote causes to numbered builds. Preserve causes and non-secret parameters for routing and audit; console prose is not a reliable replacement. Plugin-specific cause classes vary, so policy should fail safely when an unknown cause appears.

Trace a missing build from provider delivery, proxy logs, Jenkins endpoint and signature validation through branch indexing, job trigger configuration, quiet period, queue item, and executor. A 200 webhook response is not proof of a build, and a queue entry is not proof execution started. Make revision-triggering idempotent so reconciliation does not publish duplicate versions.

Goal: Practice the concrete behavior in jenkins-scm-trigger-recovery. Learn sections have no Jenkins terminal; the Jenkins lab opens the real shared service in a new full-screen tab inside your private folder.