ALM used
Azure DevOps
CI system used
Azure Pipelines (template-based pipeline via TemplatesDevops repository, using a NestJS template)
Scanner command used when applicable
Triggered automatically by the Azure Pipelines template that runs jest --coverage and generates a Cobertura XML report (coverage/cobertura-coverage.xml), which is then picked up by the SonarQube scanner.
Languages of the repository
TypeScript (NestJS / Node.js 12)
SonarCloud project URL
N/A (private SonarQube instance)
Pull Request URL
N/A (private repository)
Error observed
Basically, I have an open PR (release/SRV-30418) on a NestJS monorepo project (bk-impactor, source root: impactor) where, a few days ago, the tests were being detected and accepted by SonarQube. However, after a commit that inadvertently removed the test files, a subsequent commit restored and added more tests — yet SonarQube is showing coverage as if there are no tests at all (0% new code coverage on the Quality Gate), even though:
All tests pass locally (20/20)
The Cobertura XML report (coverage/cobertura-coverage.xml) is generated correctly and contains the new files with >95% line coverage and >98% branch coverage
The new production file (src/contract/validators/contract_gc_redistribution_validation.ts) is not excluded by any rule in sonar-project.properties
sonar.coverage.exclusions only covers /*spec.ts, test/, /node_modules/, /*.json, charts/, src/config/**
The Quality Gate fails specifically on “New Code” coverage, treating all new lines as uncovered.
Steps to reproduce
Open a PR on a branch that adds new TypeScript files with corresponding test files
In an intermediate commit, accidentally remove the test files
Restore the test files in a subsequent commit
Run the Azure Pipelines CI (which runs jest --coverage → Cobertura XML → SonarQube scanner)
Observe that the SonarQube Quality Gate fails with 0% coverage on new code, even though the Cobertura XML correctly shows the new files with high coverage
Potential workaround
Triggering a fresh pipeline run after the corrected commits appear to be the expected fix. It is unclear whether SonarQube cached the previous 0%-coverage analysis for the PR and is not re-evaluating the new code lines correctly.