-
ALM used : Github
-
CI system used : GHA
-
Scanner command used when applicable : gw sonar
-
Languages of the repository : kotlin/typescript
-
Error observed
``` Skipping load of file: “/home/runner/_work/quickflex/quickflex/build/sonar/architecture/ts/___frontend_src_app_components_simulation_components_delete-simulation-modal_delete-simulation-modal_component_ts.udg
Error raised: null
``` -
Only starting from september 22th in my ci using task gradle sonar, and after that my coverage for frontend files is ZERO
1 Like
Hey @hasnag
Can you share a bit of the logs from before/after you get this error?
Any other ERRORS / Warnings in the logs would be helpful to see as well.
I wonder if it’s related to this issue, which would have started on the same day.
Hello 
No error before or after and not related to the pinned topic neither.
the issue is that the architecture analysis is enable and I do not have any architecture.json/yml file and don’t want to enable it for now.
how can we diable this architecture analysis step ? even if i added the flag noconfig it doad the analysis.
INFO: I see that when trying to analyse frontend module, it search for jacoco file and not lcov file is it normal ?
And I still don’t know where in the analysis you’re getting an error, so logs please
Hello
I wanted to copy my logs, but today no error logs appreared, something changed in sonarcloud maybe
now logs are ok :
------------- Run sensors on project
Sensor KotlinProjectSensor [kotlin]
Sensor KotlinProjectSensor [kotlin] (done) | time=1ms
Sensor JsSecuritySensorV2 [jasmin]
35 additional JS/TS file(s) from other modules detected but not analyzed. Set ‘sonar.jasmin.modules.all’ to true to include them in the taint analysis.
No relevant JS/TS files found. Skipping taint analysis.
Sensor JsSecuritySensorV2 [jasmin] (done) | time=1ms
Sensor TsArchitectureSensor [architecture]
- Protobuf reading starting | memory total=1024 | free=125 | used=898 (MB)
- Reading SonarArchitecture IR data from directory “/home/hasna/dev/golden-path-spring-app/build/sonar/architecture/ts”
- Protobuf reading complete | memory total=1024 | free=125 | used=898 (MB)
- Build architecture.graph.ts.file_graph.default_perspective hierarchy graph complete (filtered=true) | memory total=1024 | free=124 | used=899 (MB)
- Slicing complete | memory total=1024 | free=124 | used=899 (MB)
- Cycle detection complete | memory total=1024 | free=124 | used=899 (MB)
Sensor TsArchitectureSensor [architecture] (done) | time=69ms
Sensor Zero Coverage Sensor
Sensor Zero Coverage Sensor (done) | time=5ms
But before, errors up were after : Sensor TsArchitectureSensor [architecture]
Hey there.
Interesting! We reverted a change yesterday to fix an issue, but will redeploy soon. Please watch out for this error again.
Was it failing your analysis, or just visible in the logs?
Hey
No, was not failing analysis, but we had the error I showed you up while doing the “architecture” step analysis in logs. AND the most problematic issue was that coverage for frontend was ZERO because the files ****.udg under build/architecture/ts was failing so the analyze for frontend files was not ok
but global analisys was SUCCESSFUL
Not sure the two were related in the end. But when we redeploy, the coverage issue should definitely be fixed. Whether or not the other message comes back… we’ll have to wait and see!
We had this same issue .udg files at my work not processing AND our code coverage quality gates for today’s builds started failing for unrelated code from 6 days ago.
We were unable to fix the null errors, but adding the lcov reports code in our BFF’s parent maven POM fixed our quality gate (thanks to one of our other engineers and ChatGPT for figuring this out).
Here is the snippet that was added on our parent POM:
...
<sonar.javascript.lcov.reportPaths>${project.basedir}/frontend/coverage/lcov.info</sonar.javascript.lcov.reportPaths>
<sonar.typescript.lcov.reportPaths>${project.basedir}/frontend/coverage/lcov.info</sonar.typescript.lcov.reportPaths>
...
Hope this helps others!
Our Enterprise is also affected. I narrowed it down to update from 2025.4.2 to 2025.5.0.
We have npm projects with lcov test coverage report. The lcov report worked fine but is no longer processed correctly and Sonar now reports 0 test coverage incorrectly on all NPM projects since that update:
For the following report
lcov.txt (292.9 KB)
Sonar logs fail to load any of the architecture files with same pattern
Skipping load of file: “…/build/sonar/architecture/ts/___…_component_spec_ts.udg”
Error raised: null
logs.txt (92.5 KB)
My findings:
It worked on helm chart Sonarsource Chart Repository 2025.4.2, but started failing on 2025.5.0. Community edition is not affected - tried it on community builds, but there the scan succeeds on all of them and coverage is processed correctly:
- sonarqube:25.8.0.112029-community
- sonarqube:25.9.0.112764-community
- sonarqube:25.10.0.114319-community
- sonarqube:25.11.0.114957-community
Hey @Adam_Jankovec
The coverage issue will be fixed in 2025.6, which is scheduled for early December.
As for the Architecture logs, our team will have a look!
2 Likes
Hi Colin, we just updated to 2025.6 and the error “Skipping load of file: …/build/sonar/architecture/ts/___…_component_spec_ts.udg” is gone.
Unfortunately the coverage issue is still present because our Typescript project still has no coverage.
Could you please confirm the fix was released as part of 2025.6?
We are using your sonar gradle plugin and just wrap it with our custom plugin that autoconfigures the properties. We made no changes to the plugin, but started noticing failures with the sonar server updates. After 2025.6, I noticed in the logs that now there is a complaint that the “sonar.tests” property is not being set (dont know if it was there before or not). I tried to even set it manually in build.gradle but the sonar.tests value seems to still be ignored as you can see in the attached image and logs.
sonarlogs.txt (8.3 KB)
lcov.info.txt (291.9 KB)
On top of that, now we dont even scan the sonar issues anymore as you can see in the attached images, the number of typescript issues dropped to 0.
Please tell me what more I can provide to help you investigate the cause.
Hi Colin, the SonarQube server update to 2025.6 actually did solve the coverage issue too!
However, in parallel there was an update of SonarQube Gradle plugin from 7.1.0.6387 to 7.2.0.6526. This update broke npm projects for us completely - no coverage, no issues, no duplicate. Even the latest version 7.2.2.6593 is still broken. 7.1.0.6387 is the last working Gradle plugin version.
In the attached image you can see several scans where I am searching for our inhouse platform version with the gradle plugin and its jumping from some issues to none and back finally the version with 7.1.0.6387 is working.
Could you please report this to the gradle plugin team?
Hi,
We try to keep it to one topic per thread. Otherwise it can get messy, fast.
Can you create a new thread for this new problem, please?
Thx,
Ann
Hi Ann, here is the new thread. Thanks!