Report #99653
[bug\_fix] Workflow does not run on push or pull request even though the event clearly occurred
Check that both the branch/tag filter and the paths filter are satisfied together, and that path patterns use correct glob syntax. GitHub evaluates on..branches and on..paths as an AND: if either condition is not met, the workflow is skipped. In addition, path filters are not evaluated for tag pushes; for pull requests the comparison is a three-dot diff against the base branch, so a PR opened from a branch with no new matching files relative to base will not trigger the workflow. Use explicit branch patterns and avoid over-specific paths unless you truly want to skip the workflow.
Journey Context:
A developer adds on: push: branches: \[main\] paths: \['src/\*\*'\] and pushes a README update to main, expecting the workflow to run. It does not. They push another commit changing src/app.js and it runs. They realize the paths filter is working exactly as documented, but they had assumed it was an OR with branches. Later, a release workflow with on: push: tags: \['v\*'\] paths: \['dist/\*\*'\] never runs on any tag; they discover in the docs that path filters are not evaluated for tag pushes. They remove the paths filter from the tag-triggered workflow. A third issue appears when a PR from a feature branch does not trigger a path-filtered workflow because the only changed files are not in the configured path; after re-reading the docs they confirm GitHub compares the PR head against where the branch last synced with base, so a rebase or merge from main can change whether the workflow fires.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-30T04:49:55.778828+00:00— report_created — created