I would like to understand how to use this analysis cache feature correctly. I can’t find any document on this aside from how to enable it. Yes I have enabled it and it works from one workspace perfectly everything with 100% hit rate.
Question 1:
Is analysis cache per workspace? That is does it rely on path where the workspace is checked out?
It seems like the case for me. So locally I have master checked out in 2 locations and I am using the same cache path for both analysis. There are no hits between them when switching from one to another. Note: It is exact same source code. And if I work on one workspace I get 100% hit.
Question 2:
The above issue will cause problems with PR on Jenkins and branch builds as they are checked out at different locations. What is the best approach to handle cache and reuse between different locations of source tree?
Question 3:
I use sonar.branch.name for all my build types and use the same cache for all build type on Jenkins. When I say build type I mean master, branch build and pull requests. ie. on Jenkins master build sonar.branch.name=master and for PR sonar.branch.name=PR-123 and branch build sonar.branch.name=branchname. Is this the way to do it to share the cache across from master to PR to branch builds?
I seriously need an urgent answer otherwise this tool is not useful with out cache speed up in PR.
I am talking about analysis cache as detailed in the title and also the question. This is the caching if analysis so it does not analyse the unchanged files again.
I am sorry but you are still not giving any context about your analysis and the languages you are trying to analyze. I could only guess and that is not the way to proceed.
never give anything as implicit, SonarSource supports > 20 languages and there are tens of plugins available in the marketplace.
The cache depends on the absolute path too, checkouts at different paths are not supposed to use the same cache. Even more, cache should not be uses for parallel analysis.
You should look at having a stable checkout path, i.e. on /tmp.
Having only master build updating cache and PRs copying it from master without using it is a good solution. (You may be interested by this topic SonarCFamily Cache Question)
When you say cache should not be used for parallel analysis, what do you actually mean?
multiple builds using the same cache?
or one build running sonar analysis using -Dsonar.cfamily.threads=32?
If we do run in parallel what issues are we expecting here?
Why I ask this is we still see random exceptions that was already fixed in your new releases. java.lang.IllegalArgumentException: 174 is not a valid line for pointer.
at org.sonar.api.utils.Preconditions.checkArgument(Preconditions.java:43)
at org.sonar.api.batch.fs.internal.DefaultInputFile.checkValid(DefaultInputFile.java:336)
at org.sonar.api.batch.fs.internal.DefaultInputFile.newPointer(DefaultInputFile.java:272)
at org.sonar.api.batch.fs.internal.DefaultInputFile.selectLine(DefaultInputFile.java:295)
at com.sonar.cpp.plugin.CFamilySensor.rangeOrLine(CFamilySensor.java:739)
at com.sonar.cpp.plugin.CFamilySensor.reportIt(CFamilySensor.java:660)
at com.sonar.cpp.plugin.CFamilySensor.save(CFamilySensor.java:612)
at com.sonar.cpp.plugin.CFamilySensor.process(CFamilySensor.java:520)
at com.sonar.cpp.plugin.CFamilySensor.process(CFamilySensor.java:471)
at com.sonar.cpp.plugin.CFamilySensor.execute(CFamilySensor.java:305)
at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:48)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:85)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:62)
at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:82)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123)
at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:386)
at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:382)
at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:351)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123)
at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:141)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123)
at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:72)
at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:66)
at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
at com.sun.proxy.$Proxy0.execute(Unknown Source)
at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:189)
at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:138)
at org.sonarsource.scanner.cli.Main.execute(Main.java:112)
at org.sonarsource.scanner.cli.Main.execute(Main.java:75)
at org.sonarsource.scanner.cli.Main.main(Main.java:61)
We are using SonarScanner 4.3.0.2102 and Analyzing on SonarQube server 8.3.1.
Thanks @mpaladin. Always appreciate your quick responds. Yes I was tracking it down and our CI system (Jenkins) was running multiple builds on one machine and they both use the same sonar cache. We have stopped doing that and so far so good.
I think this was the issue that was causing the exception. I will let you know if it happens again.