Problem Statement
Compare different Jenkins build trigger mechanisms. Discuss webhooks vs polling, manual triggers, scheduled builds, and upstream/downstream triggers with pros and cons.
Explanation
Webhooks (GitHub/GitLab/Bitbucket hook) are event-driven triggers where SCM pushes notification to Jenkins immediately on code push, pull request, or tag. Pros: instant feedback (builds start within seconds), efficient (no polling overhead), scalable. Cons: requires Jenkins accessible from SCM (public URL or VPN), needs webhook configuration in SCM, may require webhook authentication. Setup: install GitHub/GitLab plugin, configure webhook in repository settings pointing to https://jenkins.example.com/github-webhook/ or /gitlab-webhook/, optionally secure with webhook secret.
SCM polling uses cron syntax to periodically check repository for changes, triggering builds when changes detected. Example: H/5 * * * * checks every 5 minutes, H 0 * * * checks once daily. Pros: works when Jenkins not publicly accessible, simple setup, no SCM configuration needed. Cons: delayed builds (up to poll interval), polling overhead on both Jenkins and SCM, not scalable for many jobs. Use H (hash) instead of fixed times to distribute polling load: H/15 * * * * spreads checks across 15-minute window instead of all jobs polling at once.
Manual triggers allow on-demand builds via UI, CLI, or API. Pros: full control over when builds run, useful for testing, release deployments, or gated workflows. Cons: no automation, requires human intervention. Use for: deployment to production (requires approval), ad-hoc testing, investigating build issues. Combine with parameters for flexible manual builds: choice parameters for deployment environment, string parameters for version tags.
Scheduled builds (Build periodically) trigger at specified times using cron syntax regardless of code changes. Example: H 2 * * * runs daily around 2 AM, H H * * 0 runs weekly on Sunday. Pros: predictable timing for nightly builds, integration testing, or reports. Cons: runs even without changes (waste of resources), poor feedback loop (long delay between commit and build). Use for: nightly full builds, periodic integration tests, scheduled reports, database backups.
Upstream/downstream triggers chain jobs where one job (upstream) triggers another (downstream) on completion. Configure with "Build after other projects are built" trigger or pipeline's build step. Pros: orchestrates complex workflows, ensures dependencies run in order, reuses common jobs. Cons: can create complex dependencies, harder to debug, potential for trigger storms. Use for: multi-stage pipelines (build triggers test triggers deploy), splitting large pipelines into reusable jobs.
Best practices: prefer webhooks for instant feedback and efficiency, use polling as fallback when webhooks unavailable, use scheduled builds for time-based operations not triggered by code changes, manual triggers for gated deployments, and avoid complex upstream/downstream chains (prefer single pipeline). Understanding trigger mechanisms enables designing responsive, efficient CI/CD workflows.