CI runs on every push to the default branch and on every change request
A pipeline that only runs on tags tells you the build broke after you shipped it. Running on the default branch and on every pull or merge request catches breakage while the author still has the context.
Observable check
the CI configuration triggers on push to the default branch and on pull_request carrying no branches: filter (GitHub), or defines rules for $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH and merge_request_event (GitLab). The branches: filter keys on the pull request's base branch rather than its head, so branches: [main] runs nothing at all for a pull request stacked onto another branch, and a configuration carrying one fails this rule rather than passing it.
Where this comes from
- https://github.com/ossf/scorecard/blob/main/docs/checks.md
- https://docs.github.com/actions/reference/workflows-and-actions/events-that-trigger-workflows
Last read against these sources on 2026-07-31.
Scorecard CI-Tests: tests must run before pull requests are merged. The no-branches-filter clause was added on 2026-07-31 from an observation rather than from a source, and it is this project's own position. A repository audited that day passed this rule while three stacked pull requests ran zero CI between them, including the one that rewrote the CI workflow: its trigger was pull_request with branches: [main], which keys on the base branch, so only the bottom pull request of the stack was ever checked. That is the failure the rule exists to catch, reported as a pass. What retires the clause is GitHub changing what branches: matches on a pull_request trigger, or a project showing a case where filtering the base branch is what the maintainer needs and no unfiltered trigger will do.