Scan on pull request to decide whether a change may merge, on merge to record what landed, and on release to record what shipped. Scanning every push to every branch is usually redundant. Pick the events that each answer a distinct question and skip the rest.
What each event tells you
| Event | Question answered | Typical depth | Blocks something? |
|---|---|---|---|
| Push to a feature branch | Did my last edit break anything? | Quick | No |
| Pull request | May this change merge? | Quick, diff focused | Yes, merge check |
| Merge to default branch | What exactly is on main now? | Full | Rarely |
| Tag or release | What exactly did we ship? | Full, with inventory saved | Yes, release gate |
| Deploy | What exactly is running? | Image or artifact | Sometimes |
| Schedule | What is newly known about all of it? | Match stored inventory | No, it alerts |
Why pushes are often wasted
A push to a branch with an open pull request will also trigger the pull request scan, so you pay twice. If your CI runs both on push and on pull request, you may see duplicate runs and duplicate comments. Restrict the push trigger to the default branch, and let pull requests cover branches.
Steps
- List the questions you need answered, from the table.
- Map each to one trigger. Remove any trigger that duplicates another.
- Set depth per trigger. Pull request scans should be fast, because a slow check gets bypassed. Release scans can take longer.
- Decide which results block. Start with a narrow rule, such as critical findings with a fix, and widen later. See what a release gate should block.
- Store results from merge and release scans, because those are the records you will be asked for later.
- Add a scheduled job for what none of these events can see. See scheduled or event-driven scans.
Path filters and skipping
A change that touches only documentation does not need a dependency scan. Use path filters on lockfiles and manifests so scans run when they could matter. Be careful with filters on monorepos, where a shared package change affects many services. A related post covers per-package scans with path filters.
Try it yourself
Open the demo to see a pull request gate in action. Click a failing check and read what it blocks and why.
Click through it at your own pace, or open it full screen.
Quick check
Do I need both a pull request scan and a merge scan?
Often yes. The pull request scan gates the change. The merge scan confirms the final combined state, which can differ if other changes landed first.
Is a release scan redundant if every merge is scanned?
Not if you need a dated record of the exact released artifact and its inventory.
Last reviewed: 19 October 2026.
