Open-data validators should rebuild every night even when no one pushed that day. Which trigger type fits?
Select an answer to reveal the explanation.
Short Explanation
A scheduled trigger is the night janitor for open-data validators—you can count on it to run on the clock even when nobody pushed. Manual runs depend on someone noticing, while outage tickets and mayoral terms are not a nightly cadence.
Full Explanation
A cron or scheduled trigger runs CI on a time cadence independent of pushes, which is what you need for routine rebuilds when the repository is quiet. Open-data validators should run nightly so datasets are re-checked even when no developer pushed that day. This trigger fits because open-data quality can drift due to upstream feed changes, credential expiry, or schema shifts outside the city's Git history; waiting for a human push would miss those regressions. Running the validators manually whenever a developer notices the dashboard needs updating fails because memory is not a schedule and can leave multi-day gaps in coverage. Disabling automation and validating once per mayoral term fails because term-length gaps are not continuous validation and could let corrupt or stale open data persist for years. Triggering builds only from production outage tickets after citizens complain is reactive incident response, not proactive nightly validation. Exam caveat: scheduled jobs still need ownership, alerting, and non-business-hour capacity planning; nightly failures must notify someone rather than leave a red dot for Monday. Practical check: configure a cron trigger, confirm a run starts on schedule without a push, deliberately break a validation rule and confirm the nightly job fails and alerts, and document timezone assumptions so daylight-saving shifts do not silently skip runs.