Triggers

A workflow declared with on: push runs on every push, on every branch, even when the commit only touches the README.md file. On a team of five, that quickly adds up to several hundred runs per week, most of which verify nothing useful. The problem isn't just the cost in billed minutes: it's the queue. When twenty pointless runs are occupying the runners, the one blocking an urgent merge waits behind them.

The most expensive case is a quieter one. You push three commits in a row to a working branch — a fix, something you forgot, a typo. GitHub starts three full runs in parallel, and the first two test a state of the code that nobody will ever merge. They will run to completion, tie up runners, and their results will be ignored. Choosing your triggers and knowing how to cancel is what separates a fast pipeline from one that people end up bypassing.

push and pull_request: the classic duplicate

These two events look alike but don't test the same thing. push tests the contents of the branch as it is. pull_request tests, by default, a simulated merge between the source branch and the target branch — an ephemeral merge commit that exists in no repository. That is precisely the state that matters before a merge, and it's what lets you detect a semantic conflict: two changes that are each valid on their own but incompatible together.