bermudalamb
e6d9079097
The quality gate has been grading the entire codebase rather than what changed. The server's new-code period is PREVIOUS_VERSION, but sonar.projectVersion was never set anywhere — not here, not in the workflow — so every analysis recorded "not provided" and there was no previous version to diff against. SonarQube's fallback is to treat everything as new. The tell was visible in the measures all along: new_lines read 9460 against a total ncloc of 5496, and new_coverage tracked overall coverage to within two points. Both are what you would expect if "new code" meant "all code", and neither is surprising enough to notice unless you go looking. This is the fourth time the project has hit the same shape — a tool reporting a plausible number for something other than what was asked. Verified with a scan against the scratch key rather than by reasoning about the config. The analysis now records version 1.0.0, ncloc holds at 5557 so nothing was silently dropped, and new_lines falls from the whole codebase to 151 — the window is now the diff. One consequence worth expecting rather than discovering: a narrow window makes new_coverage volatile. The verification scan reported 0.0% on two lines to cover, because two uncovered lines is all it takes. The number will settle as commits accumulate and the window widens, but the gate will be jumpy for the first few merges, and it will not simply turn green on its own. Left at 1.0.0 to match both package.json files. Nothing enforces that they stay in step, so the comment says to move all three together. Refs #79 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
48 lines
2.7 KiB
Properties
48 lines
2.7 KiB
Properties
# Scan configuration, kept here rather than as inline -D arguments in
|
|
# .gitea/workflows/sonarqube.yml so that a local scan and a CI scan analyse the
|
|
# same thing. Only the host URL and token stay in CI secrets.
|
|
|
|
sonar.projectKey=redefined-designs
|
|
sonar.projectName=redefined-designs
|
|
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
|
|
# EXECUTION SUCCESS. See #67. tsconfig.sonar.json is an analysis-only mirror;
|
|
# both it and this line go away once the server can parse "bundler".
|
|
sonar.typescript.tsconfigPaths=backend/tsconfig.json,frontend/tsconfig.sonar.json
|
|
|
|
# Test sources, so they are analysed under the test rule set rather than as
|
|
# production code — or, as before, not at all.
|
|
sonar.tests=backend/tests,frontend/tests
|
|
|
|
# Coverage. Three reports because the suites cover genuinely different things and
|
|
# jest would otherwise overwrite one with the other: the unit suite alone reports
|
|
# ~11% because everything in src/routes is exercised by the integration suite,
|
|
# not by it. SonarQube merges them, so a line covered by any suite counts.
|
|
#
|
|
# Read the frontend number with suspicion. It comes from Playwright through an
|
|
# istanbul-instrumented dev server, and istanbul marks a line covered when the
|
|
# browser ran it — a component renders during an end-to-end test and reports as
|
|
# covered with nothing asserting anything about it. See #61's design doc.
|
|
sonar.javascript.lcov.reportPaths=backend/coverage/unit/lcov.info,backend/coverage/integration/lcov.info,frontend/coverage/lcov.info
|