The scanner ran with no branch name, so every analysis was recorded against the project's main branch whatever branch produced it — and the job runs on every push, so a feature branch replaced main's results.
Not theoretical. While dismissing the first scan's false positives,
the dashboard was showing the head of an unmerged branch, and two findings
genuinely open on main read as FIXED on the strength of a commit main
does not contain. I only noticed because I re-fetched before dismissing
rather than working from my triage file.
Wrong in both directions: a branch that removes findings makes main look
clean before its fix merges; one that adds findings makes main look
broken when it is not. Once the gate is binding rather than reporting, it
would follow whichever branch built last.
A branch other than main now passes -Dsonar.branch.name and keeps its
own history; main passes nothing and stays the default analysis. I
verified the shell logic for all three cases — feature branch, main, and
GITBAY_REF unset.
The step still ends in || true, so an instance whose plan does not offer
branch analysis loses the branch scans rather than the build — and
main stops being overwritten either way, which is the part that matters.
Closes #154
retargeted from review-standing to main: !258 merged
2026-09-05 01:22 UTC