Path filters skip a rebased branch's code jobs, so unverified code looks green #176

closed cmc opened this on 2026-09-06 20:02 UTC · milestone v1.15.0

Discussion

cmc 2026-09-06 20:02 UTC

After a rebase or any force-push, test, sonar and vuln do not run, and the branch shows only build: success. The code jobs are neither run nor recorded as skipped.

Reproduced repeatedly today landing a four-branch stack. Each time main moved, the stack was rebased onto it and force-pushed; every push queued exactly one job (build), while the branch's Go changes went unbuilt and untested:

bookmarks-146
    b4a2206e build:success              <- after rebase
    967c3c81 build:success              <- after rebase
    adc587d4 build/sonar/test/vuln:cancelled
    ee5ecbcb build:success sonar:success test:failure vuln:success

The cause looks like the changed-file set for a push being computed from the previous tip to the new tip. For a rebase that diff is only whatever the new base added — here wiki files — so every path filter keyed on **.go or internal/** decides the job is not needed. The branch's own changes are invisible to the filter because they are on both sides of that diff.

Two consequences, the second worse than the first:

  1. A rebased branch reports green without its suite having run. A reader of build list sees build: success and nothing failing. Merging on that is merging unverified code, and fast-forward-only repositories rebase constantly, so this is the normal path rather than an edge case.
  2. Nothing is recorded as skipped, so #172's guarantee does not hold here — there is no row saying the job was deliberately not run. require_checks sees no result rather than a skip.

The filter should almost certainly compare against the merge base with the target, which is what #171 already established for a branch's first push, rather than against the previous tip. The question worth settling is whether a force-push should be treated as a first push for this purpose: the branch's relationship to its target is what a filter is deciding about, and that is what the merge base expresses.

Until then, treat a green run on a rebased branch with suspicion, and check that the last full run's content matches what is being merged.

Ref #169, #171, #172.

closed by commit 03620cf7bd by cmc: ci: filter a rewritten branch against the merge base, not the old tip

2026-09-06 22:25 UTC

referenced in commit dfb48fe52b by cmc: hookd, wiki: every push shape, what CI makes of it, and a test per row

2026-09-08 07:18 UTC