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

2026-08-20T13:18:25-05:00

bermudalamb commented

2026-08-20 13:18:25 -05:00

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

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>

bermudalamb added 1 commit 2026-08-20 13:18:26 -05:00

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

SonarQube Analysis / sonarqube (pull_request) Successful in 13m35s

Details

Tests / lint (pull_request) Successful in 2m4s

Details

Tests / backend-unit (pull_request) Successful in 41s

Details

Tests / frontend-e2e (pull_request) Failing after 9m22s

Details

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>

bermudalamb self-assigned this 2026-08-20 13:19:01 -05:00

bermudalamb added this to the Code Quality and Hardening project 2026-08-20 13:19:09 -05:00

bermudalamb moved this to In Progress in Code Quality and Hardening on 2026-08-20 13:19:14 -05:00

bermudalamb merged commit 931d8f8167 into main

2026-08-20 13:19:36 -05:00

bermudalamb deleted branch feature/79-sonar-project-version

2026-08-20 13:19:37 -05:00

bermudalamb referenced this pull request

2026-08-20 15:27:58 -05:00

SonarQube analyses the code but imports no test coverage, so its quality gate is measuring nothing #61

bermudalamb moved this to Ready for Release in Code Quality and Hardening on 2026-08-20 15:44:38 -05:00

bermudalamb moved this to Released in Code Quality and Hardening on 2026-08-21 12:12:06 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bermudalamb/redefined-designs#80