Hey,
We have a sonarsource/sonar-scanner-cli being executed with -Dsonar.host.url=https://sonarcloud.io
During the quality gate scan I see:
“Server-side caching is enabled. The Java analyzer was able to leverage cached data from previous analyses for 0 out of 491 files. These files will not be parsed.”
The cache should exist, so I’m trying to debug why it doesn’t work. If I get it right that cache is being persisted on sonarcloud.io.
Is there any way to see the content of that cache?
Hi,
Welcome to the community!
There’s no good way to see that cache. What’s your context? The cache is only used during PR analysis. Is that what you’re performing here?
Thx,
Ann
Yes, quality gate, afaik that is only for PRs… and either the cache is empty or for whatever reason it just cant find the matching entries. I can’t see anything useful even with trace logging.
Hi,
To be clear, are you in a PR-analysis context?
Also, has the PR’s target branch been analyzed? That’s where the cache comes from.
Ann
Yes to all of your questions. The target branch has got Sonar running on it as well, but that is what I’m trying to see, if the entries are in the cache as expected or not, and if they are why can’t it be found.
It seems the Python code could find entries in the cache, the Java does not:
16:24:59.638 DEBUG: Compatible cached data version '1.29.0.10185' found.
16:25:00.173 INFO: Server-side caching is enabled. The Java analyzer was able to leverage cached data from previous analyses for 0 out of 2096 files. These files will not be parsed.
16:50:15.522 DEBUG: Compatible cached data version '1.29.0.10185' found.
16:50:15.961 DEBUG: Compatible cached data version '10.6.0.31509' found.
16:50:15.977 INFO: The Python analyzer was able to leverage cached data from previous analyses for 2 out of 2 files. These files were not parsed.
Hi,
What are the changes in your PR versus its target branch? Is it only code, or dependencies as well? Because a change in underlying dependencies could easily explain why the cache wasn’t usable for the PR.
Ann
It doesn’t matter. This happens at every PR. Regardless of the change.
Hi,
I’ve flagged this for more expert eyes.
Ann
I have tweaked my run, and noticed something:
INFO: ------------- Run sensors on module ***
INFO: Load metrics repository
INFO: Load metrics repository (done) | time=164ms
INFO: Sensor cache enabled
INFO: Load sensor cache
INFO: Load sensor cache (3 MB) | time=3330ms
INFO: Sensor JavaSensor [java]
INFO: The Java analyzer is running in a context where unchanged files can be skipped. Full analysis is performed for changed files, optimized analysis for unchanged files.
WARN: Invalid character encountered in file /workspace/***/src/main/java/com/***/***/***.java at line 107 for encoding UTF-8. Please fix file content or configure the encoding to be used using property 'sonar.sourceEncoding'.
INFO: Server-side caching is enabled. The Java analyzer was able to leverage cached data from previous analyses for 0 out of 6772 files. These files will not be parsed.
INFO: Using ECJ batch to parse 6772 Main java source files in a single batch.
INFO: Starting batch processing.
INFO: 50% analyzed
Could it be that the encoding issue disables this feature for the whole module?
EDIT: unfortunately seemingly no
INFO: Sensor JavaSensor [java]
INFO: The Java analyzer is running in a context where unchanged files can be skipped. Full analysis is performed for changed files, optimized analysis for unchanged files.
INFO: Server-side caching is enabled. The Java analyzer was able to leverage cached data from previous analyses for 0 out of 6772 files. These files will not be parsed.
INFO: Using ECJ batch to parse 6772 Main java source files in a single batch.
INFO: Starting batch processing.
Hi @Balazs_Nemeth , and welcome for the community!
This problem is likely not because of encoding. If so, caching would just skip that one file, assuming that the contents of the file is different from the cache contents.
This problem is likely caused by the SonarSecurity plugin. We had an internal bug report (so I can’t share the links) with the same symptoms: 0 out of n files cached. It turned out that the plugin, which injects its own rules into the SonarJava plugin, requested the unnecessary reparsing of source code files under specific circumstances. This, effectively, disables caching for the whole SonarJava plugin.
We have a ticket about this: SONARSEC-3439.
(I can’t see this link either.)
So is there anything I can do to avoid this or I can only wait for a fix?