Merge pull request 'chore(ci): declare sonar.projectVersion so the new-code period means something (#79)' (#80) from feature/79-sonar-project-version into main

Reviewed-on: #80
2026-08-20 13:19:32 -05:00
parent c2964482e0 e6d9079097
commit 931d8f8167
1 changed files with 16 additions and 0 deletions
@@ -8,6 +8,22 @@ sonar.sources=backend/src,frontend/src
 sonar.exclusions=**/node_modules/**,**/dist/**
 sonar.sourceEncoding=UTF-8
 # The new-code period. Without this the gate silently grades the entire codebase
 # rather than what changed: the server's period is PREVIOUS_VERSION, and with no
 # version ever declared there is no previous version to diff against, so every
 # line counts as new. The symptom is new_lines (9460) exceeding total ncloc
 # (5496) and new_coverage tracking overall coverage to within two points, which
 # looks like a working gate right up until you check. See #79.
 #
 # PREVIOUS_VERSION baselines at the first analysis carrying a given version, so
 # "new code" here means everything since this number last changed. Bump it when
 # a release is cut and the baseline moves with it; leave it alone and the window
 # simply keeps widening, which is the honest behaviour rather than a silent one.
 #
 # Kept in step with the version in backend/package.json and frontend/package.json
 # by hand. Nothing enforces that, so change all three together.
 sonar.projectVersion=1.0.0
 # Without this the analyser auto-discovers frontend/tsconfig.json, chokes on its
 # "moduleResolution": "bundler" — unrecognised by the TypeScript bundled with
 # SonarQube 9.9 — and silently drops all 34 frontend files while still exiting