I have a SonarCloud scan running in an Azure Pipeline against a typescript / react.js repo in Azure Devops. It’s a newly created SonarCloud org and project and am running the scans on a feature branch in preparation to merge it if I can get this to work. We have 2 other SonarCloud projects (.NET repos) that are running w/o issues. (also scanning feature branches)
The scan on the typescript repo is running in the pipeline seemingly w/o any problems, but the results are not showing in the SonarCloud portal. Zero code smells, security issues, coverage and the code tab only shows 2 files and the quality gate passed message. (There are about 100 that are scanned) I’ve created eslint json reports, lcov coverage reports and jest-sonar unit test reports. The scanner is finding them, seems to be processing them, but the reports also do not show up in SonarCloud.
According to the debug logs, it is in fact scanning the files and is finding flaws and the reports are uploaded to SonarCloud without any issues. I’m not seeing any errors in the logs.
I’ve tried just about everything I can find to configure this and can’t seem to get it to work. Right now I have all of the scan config settings in a sonar-project.properties file and I’m using the SonarCloud Azure Devops tasks to do the prepare, scan and publish. HELP!! Thanks in advance.
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.
is there specific information i can give you to help solve the issue or look into it on the backend? the log file has approximately 9000 lines and scrubbing it would take a significant amount of time
What scanner are you using to analyze this project? If it’s not fundamentally a .NET project, you can turn off debug mode and still get decent logging.
The coverage report is created by jest-junit and test results by jest-sonar-reporter. Also note that it also does not work when excluding these reports from the properties file.
I’m back to wanting your analysis logs. You’re using scannerMode: 'CLI' , so you’ll still get decent logging if you turn debug off.
Regarding your properties:
First, I assume both of these point to the workspace? If so, there’s no need to provide a path from home. Just use ..
Second, you’ve specified that everything in s is both tests and source files. It’s not ideal, but I understand some projects are structured that way.
You then try to untangle that with inclusions and exclusions:
The problem is that your test inclusions and your (source) exclusions should match up. They don’t. You’ve identified **/*.spec.tsx as test files, but excluded **/*.spec.ts according to what you’ve pasted. Additionally, that **/*.spec.ts unfortunately overlaps with what you’ve explicitly included for source files: **/*.ts (since *.spec.ts is fully described by *.ts, where * is greedy).
As a side note, **/node_modules/** doesn’t exclude any files, since ** means “0-n directories”. Did you mean **/node_modules/**/*?
The tests exist in '_ _ tests _ _ ’ (two underscores wrapping tests) directory under each component, so the test sources would have to be wildcarded which you cannot do
should sonar.test.inclusions be removed completely?
i initially had . as the paths with the same results and switched to the the explicit paths since the reports are in a directory above system working directory. can sonar.testExecutionReportPaths interpret …/ correctly?
Ehm… You need to be careful that the paths in the reports match the paths analysis sees.
All other things being equal, I would download your reports into the project directory so that you didn’t have to ../, but I understand if you need to do that to make the pathing worth.
I ended up keeping with the full path to the report artifacts. I also merged the code to main and am getting reporting on the main branch, but the feature branch did not report. So I am able to work with this for now.