Trigger filter omits the guarded files

What goes wrong

A check runs only when the changed files match a path or trigger filter, and that filter does not list all the files the check is meant to cover. Edits to the uncovered files produce a green result because the check never ran. The reader relies on a passing pipeline to mean the check was evaluated.

Example

A suite proving a payout path runs only when the payment folder changes, so editing the rate lookup it depends on ships with the suite never executed.

Not to be confused with

Not a weak or incomplete check: the assertions are right and would catch the regression, so this differs from a guard that inspects less than it claims, where the check does run.

Discovered by

@sks24git GitHub

Field notes · 12

@sks24git2026-11-03beat 2 review rounds

A guard against clashing test names ran when a test file was added, but not when a package marker file was deleted. Deleting that marker renames every module inside, so a clash slips past and breaks the whole suite.

Trigger name checks on deletes as well as adds. Removing a package marker changes names too.
List every event that changes what you guard. Adds are only the obvious one.

@sks24git2026-11-02beat 1 review round

A test picker chose schema tests only if they called rollback, so tests that read the revision folder another way were left out. A new revision could fork the chain and still pass the pull request run.

Select tests by what they read, not how they call it. One verb misses the files that load the same data another way.

@sks24git2026-10-30

A step's logic moved from a config file into a script, but the change filter still treated only the config file as shared. A change to the script alone now runs no tests and only breaks the main branch later.

When you move logic out of a watched file, move the watch too. The filter follows the file name, not the code.

@sks24git2026-10-29

A new rule lived in a script that the pipeline skips for exactly the inputs the rule was written for. Its unit tests fed the script those inputs directly, so they passed while the rule never ran in the pipeline.

Trace the caller's guard before trusting a unit test. A test that calls the function directly can't see the condition that keeps it from running.

@sks24git2026-10-28beat 5 review rounds

A test selector listed changed files with rename detection left on, so a moved data file showed up only under its new name. Code still naming the old path never got selected, and the slim run stayed green.

Diff with renames off when you seed by path. A rename is a delete plus an add, and the delete is what breaks callers.
Match the flags of the step you mirror. Two listings, two answers.

@sks24git2026-10-25beat 1 review round

A duplicate-name lint blamed new groups on the files a change touched, and went strict only when its baseline changed. Edit the lint's rules and each new group reads as inherited; the next unrelated change goes red.

A checker's code is part of its baseline. Judge a rules edit as strictly as an allowlist edit.
Attribute by cause, not by file. A rule change touches no module yet creates every new group.

@sks24git2026-10-15beat 1 review round

A new test file landed beside the suite, but the runner only executes modules named in a fixed list. Every check in it passes locally and never runs in CI, so its logic can regress with a green build.

Wire every new test into the gate in the same change. A test CI never runs guards nothing.
Read CI's module list, not your local run. Local green proves it passes, not that CI runs it.

@sks24git2026-10-06beat 1 review round

A test reads a file from outside its module, but CI starts that test only when its own module changes. A PR that edits just that file skips the test, and the build cache would serve a stale pass anyway.

Run a check where the change lands. A guard in another job sleeps through the PR that breaks it.
Declare every file a test reads as an input. Or the cache replays a green run.

@sks24git2026-09-10beat 2 review rounds

A test fixture was extracted into a file that matched no path filter, so a fixture-only edit would skip the one job running that suite. The suite's own entry still matched, which hid the gap.

Extracting a fixture moves code out of the filter that guarded it. Add the new file to the filter in the same commit.
Ask which edits can now change behaviour while the suite sleeps.

@sks24git2026-09-10beat 2 review rounds

An isolation suite runs only in a job whose path filter lists neither the code it exercises nor the test file itself. Change exactly that code and the suite runs nowhere in CI.

A test selected by a path filter is only as good as the filter. List the files the suite guards, or it sleeps through their change.

@sks24git2026-09-10beat 3 review rounds

The suite that proves a money path runs only when a CI path filter names a changed file. The filter missed the rate lookup the path had just started calling, so the pricing half could ship unproven.

A path filter is part of the test. When a proof gains a dependency, add that file to the filter in the same commit.
A suite that does not run is a suite you do not have.

@sks24git2026-09-10beat 1 review round

A fix came with a test, but the job that runs it is gated by a path filter none of the changed files match. The suite exists and never executes on the code it guards, so the next edit reverts the fix with a green build.

A new test needs its trigger checked, not only its assertions. An unmatched path filter is a suite that runs nowhere.