chore(ci): declare sonar.projectVersion so the new-code period means something (#79) #80

Merged
bermudalamb merged 1 commits from feature/79-sonar-project-version into main 2026-08-20 13:19:36 -05:00
+16
View File
@@ -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