Four jobs ran on every push to every branch. Two of them never informed a merge decision:
- sonar ends in
|| true, so it is report-only and cannot fail a build. Analysing every push of a branch that is about to be squashed away informs nobody, and a stack being rebased analysed the same tree four times. The per-branch handling inside the step exists so a branch does not overwrite main's results (#154) — which is an argument for analysing main. - vuln runs
govulncheck@latest, and its own comment says it scans "against the database as it is today, not as it was at commit time". That is a time-dependent signal wearing a push-shaped trigger: an advisory published against code nobody touched stayed invisible until someone happened to push, while a rebase that changed nothing re-scanned it.
Both become scheduled jobs — vuln at 03:00, sonar at 03:30. A scheduled job
is registered by a default-branch push, so they track main. build trigger krz/gitbay vuln runs one on demand, which is what to do before tagging a
release; deploy/audit.sh covers the same ground in the release checklist.
Branches now run build (seconds) and test (the suite, and the only job that
gates a merge). Two jobs per push instead of four, and vulnerability coverage
gets better rather than worse — a nightly scan notices an advisory that no push
would have surfaced.
I first tried restricting sonar with paths: ["**"]. That is wrong: path filters
select on changed files, not on branch, so it would have run on every push
exactly as before. Scheduling is the mechanism that already expresses "track
main". Validated by parsing the file with ci.Parse rather than by eye.
The dedupe half of #177 — keying on tree rather than commit sha, so a rebase reuses results — is not in this merge request.
Stacked on !296.
Closes #177
retargeted from ci-rebase-diffbase-176 to main: !296 merged
2026-09-06 22:25 UTC