Triggering Workflows on Pull Requests and Protecting Branches
Fast recall
Quick revision
Core answer
on: pull_request: to trigger a workflow when PRs are opened or updated, then enable branch protection rules in GitHub settings to require that workflow's status check to pass before merging.Whether you understand how CI integrates with GitHub's code review workflow to prevent broken code from reaching protected branches.
Triggering workflows only on `push` to main, which means broken code is merged before CI catches it, rather than blocking the merge via PR checks.
Mention `pull_request_target` for workflows that need write access while running against fork PRs, concurrency groups to cancel redundant runs, and `paths:` filters to run only relevant checks when specific files change.
Interview-ready guide
Interview answer
Branch protection rules and workflow triggers together enforce the quality bar that code must meet before merging. The branch protection rules define the required status checks; the workflow triggers define when those checks run.
PR workflow triggers
on: pull_request: types: [opened, synchronize, reopened]is the standard trigger for CI validation — it runs on new PRs, every push to an existing PR, and reopened closed PRs; this covers the complete PR lifecyclegithub.event.pull_request.head.repo.full_name == github.repositorychecks whether the PR is from the same repository or a fork — useful for conditionally enabling steps that need secrets, since fork PRs cannot access repository secrets- Add
paths:filters to skip expensive jobs when only documentation changes:paths-ignore: ['**.md', 'docs/**']avoids running a 5-minute test suite when only a README changed
Branch protection configuration
- Required status checks enforce that specific workflow jobs must pass before merge; add the CI job name exactly as it appears in the workflow YAML to the required checks list in branch protection settings
- Enable "Require branches to be up to date before merging" — this forces PRs to rebase on main before the final required check runs, preventing a PR that passes tests against an old main from merging after a breaking change landed on main
- "Require linear history" disables direct merge commits and requires squash or rebase merges — enforces the team's chosen branching strategy at the repository level rather than through convention
CODEOWNERS and approval requirements
- A
.github/CODEOWNERSfile assigns automatic review requirements by file path — changes tosrc/main/java/security/require the security team's approval; changes tohelm/require the platform team's approval regardless of who opens the PR - Combine CODEOWNERS with "Dismiss stale pull request approvals when new commits are pushed" — approvals do not carry forward when the PR adds commits after review, preventing approvals that predate the actual changes being reviewed
Triggering Workflows on Pull Requests and Protecting Branches
Direct Answer
Use on: pull_request: to trigger a workflow when PRs are opened or updated, then enable branch protection rules in GitHub settings to require that workflow's status check to pass before merging.
Common Mistakes & Pitfalls
Triggering workflows only on push to main, which means broken code is merged before CI catches it, rather than blocking the merge via PR checks.
Check your understanding
Answer these without looking back at the article.
- How do you require multiple status checks from different workflows before merging?
- What is the difference between `pull_request` and `pull_request_target` triggers?
- How do you automatically dismiss stale pull request reviews when new commits are pushed?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.