A small services team wants an automation that triages new GitHub issues, labels bugs, and assigns owners. It should run only when an issue is opened, ignore comments and pushes, and avoid duplicate runs. Which trigger selection and configuration best meets these automation needs?
Select an answer to reveal the explanation.
Short Explanation
You'll save your team a lot of noise when your automation reacts only as new issues pop up, like a doorbell that stays silent until someone's at your door. That focused trigger keeps labels and owners tidy without extra runs from comments or pushes.
Full Explanation
The correct selection works because it limits execution to the single creation moment and scopes side effects to that payload, which directly satisfies run only on open, ignore unrelated activity, and natural idempotency since each issue opens once. The reopened-inclusive variant fails by lifecycle scope because reopened is a distinct state transition often used for regressions or accidental closes, so adding it widens the trigger beyond the only on opened constraint even though uniform labeling across lifecycles is otherwise best practice for support teams. The comment-enriched variant fails by event filtering because using new comments as added context reintroduces execution on conversational activity the requirement explicitly excludes, trading precise triage for richer assignment at the cost of extra noisy runs and higher maintenance. The nightly backfill variant fails by duplication control because a scheduled reapplication pass creates additional runs outside the opening event and can relabel or reassign work already triaged, which conflicts with avoid duplicate runs even though backfills are commonly used for resilience against missed webhooks. Exam caveat: distinguish commonly desirable robustness patterns like handling reopen, comment context, or scheduled reconciliation from strict least-trigger wording that demands only one event and no repeats. Practical check: inspect the trigger filter and run history to confirm only opened events appear with one run per issue and that comments, pushes, and timed jobs produce no executions.