City Jenkins should start a pipeline automatically when developers push to the municipal Git remote. Which trigger mechanism fits?
Select an answer to reveal the explanation.
Short Explanation
You can use a webhook as the doorbell from Git to Jenkins: when you push code, the pipeline starts. Weekly paper requests, hoping an admin notices commits in person, or annual-only builds leave changes waiting instead of responding to each push.
Full Explanation
A webhook is a trigger that starts CI when the Git remote receives a push, giving you prompt feedback on municipal code changes. Configure the municipal Git remote to send push events to Jenkins so each developer push automatically starts the pipeline. This removes human latency: Jenkins learns of commits as soon as the remote does, a foundation of continuous integration for city services. Having an operator review a weekly paper request and manually start the pipeline fails because paper-process delays defeat CI’s purpose and cannot keep pace with modern municipal delivery. Polling nothing and hoping an admin notices new commits in person is not an event-driven trigger and can leave commits undetected for long periods. Scheduling only annual builds ignores how often code is pushed and does not provide push-driven continuous integration. Exam caveat: harden webhook endpoints with shared secrets, allowlisted source IPs, and TLS so unauthenticated Internet callers cannot trigger arbitrary municipal Jenkins jobs. Practical check: configure the Git remote webhook, push a trivial commit to a test branch, confirm the pipeline starts within the expected latency, verify that the webhook secret is required, and monitor for missed deliveries.