Choose triggers carefully

Start from the behavior you can observe. Documentation-only changes can skip a heavy build, and deployment runs only from the protected default branch.

Trigger configuration is part of security and cost because it decides which code runs and with what context. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to trigger privileged work on every event and filter it later inside a shell command. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to narrow events in workflow syntax and test pull request, fork, branch, tag, and manual cases. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Create one workflow whose trigger, runner, permissions, commands, and failure behavior are obvious. Record enough evidence that another developer can repeat the result without relying on your memory.

Build a trigger table and create one commit for each important included and excluded path. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.