chore(ci): report web-app coverage to SonarCloud - #1001
Conversation
sonar.sources has listed web-app/src since the property file was written, but sonar.javascript.lcov.reportPaths only ever pointed at lib/coverage. Every file under web-app/src has therefore counted as uncovered, and adding tests there could not change that. web-app now runs vitest with the v8 coverage provider and writes lcov. The scan moves out of the lib job into its own: it needs the report from the web-app job, and that job already needs lib, so the scan could not stay where it was. Both jobs upload their lcov as a short-lived artifact for it to collect. The new job is in ci.needs so a failed scan still fails CI, as it did when the scan was a step of lib. Its steps are individually guarded rather than the job, because job-level if cannot read env; on forks and dependabot runs they all skip and the job reports success. Test files are excluded from analysis. They sit beside the code they cover under web-app/src, so without that they would count as main source with no report behind them, and adding a test would lower the new-code ratio. This does not by itself clear the quality gate. App.tsx is the bulk of the new code in any web-app change and stays at 0%: App.test.tsx drives it through a real browser against vite preview, so it runs in a process the v8 provider never instruments. Signed-off-by: Dave Mihalcik <dmihalcik@virtru.com>
|
Warning Review limit reached
Next review available in: 59 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
1 participant
Split out of #1000 to keep that PR to the demo-app change.
What
sonar.sourceshas listedweb-app/srcsince the property file was written,but
sonar.javascript.lcov.reportPathsonly ever pointed atlib/coverage.Every file under
web-app/srchas therefore counted as uncovered, and addingtests there could not change that.
web-appruns vitest with the v8 coverage provider and writes lcovlibjob into its ownsonarscanjob. It needs thereport from the
web-appjob, and that job alreadyneeds: lib, so the scancould not stay where it was. Both jobs upload their lcov as a 1-day artifact
under
web-app/src, so otherwise they count as main source with no reportbehind them, and adding a test would lower the new-code ratio
What this does not do
It does not by itself clear the quality gate.
App.tsxis the bulk of the newcode in any web-app change and stays at 0%:
App.test.tsxdrives it through areal browser against
vite preview, so it executes in a process the v8 providernever instruments. Crediting
App.tsxneeds either more pure logic extractedinto unit-testable modules, or browser-coverage collection wired into lcov.
Worth a separate conversation whether a demo app belongs in the SDK's quality
gate at all.
Risk
This touches build flow.
build-and-test / sonarscanis a new check. If branch protection listsrequired checks by name, it may need adding
SonarCloud Scanstep is gone frombuild-and-test / lib, andlibnolonger does a full-history checkout, since it was only fetching depth 0 for
sonar's benefit
sonarscanis inci.needs, so a failed scan still fails CI exactly as itdid when the scan was a step of
libif: fromJSON(env.do_sonarscan)ratherthan the job, because job-level
ifcannot readenv. On forks anddependabot runs every step skips and the job reports success
How to test
Check
web-app/coverage/lcov.infoexists and hasSF:records for the filesunder
web-app/src(App.tsx,session.ts,config.ts, ...). Expect near-zerocoverage on this branch: the only test here is the browser-driven
App.test.tsx.The first real unit-tested file,
src/fileNames.ts, arrives with #1000; onceboth are merged its lcov record should read 18/18 lines.