"sonar.cfamily.cache.enabled" and "sonar.cfamily.cache.path" properties are deprecated.
Visit the documentation page for more information about analysis cache configuration
The documentation for the new analysis parameter sonar.cfamily.analysisCache.mode only says how to change the cache strategy from the default (server) to local file system (fs). I believe I need to disable because we run multiple analysis jobs and they don’t always have the same base code version (i.e. a pull request off branch A is analyzed, then one off of branch B is analyzed, then one off of branch C, etc.). So, the cache seems useless to me as it will not identify the correct set of changed files for a given analysis.
Whether my use case is valid or not, it seems that you should not be deprecating parameters without specifying a replacement with equivalent functionality.
Thanks for reporting this. The embedded documentation was dropped in 9.8 and the printed link wasn’t updated. Should be fixed in SQ 9.9.
A server cache would be useful in your case. Because there is a separate cache for each branch. It is updated when that branch is analyzed. And each PR uses the cache of its base branch.
This is going to be part of 9.9 Doc for server cache:
For branch analysis, an analysis cache is stored on the server per branch.
For pull request analysis, the cache of the base branch is used and not persisted.
If no cache is found, the cache of the Main branch is used.
You can choose between server cache or filesystem cache. The documentation points to how to get the equivalent behavior if you were using a filesystem cache. Disabling the cache was never a feature, it was a workaround until the cache implementation becomes stable.
The idea is that you get server cache, like for most languages, by default and you don’t have to worry about it or about its implementation details. If you have a special workflow, you can optimize the caching mechanism by having granular control using a filesystem cache.
When the base branch has no cache we have two choices:
Not use any cache. Definetive 0 cache hit
Use the cache of the main branch. Which will lead to either 0 cache hit if the main and the current branch are totally unrelated and some cache hit if the branch has some shared code with the main branch.
The second option cannot be worse than the first one and in some common situation, where the branch is taken from the main one, it is better.
Why would using a branch with some shared code (and some code that is not shared) be a good thing? If we can do an analysis without relying on assumptions (which may be wrong) about the nature of the code changes, why not go that route? Yes, performance will be worse if we use no cache, but won’t the results be more reliable? In the end, this is an edge case, so not a big deal either way.
@andrew-garland, I know it is an edge condition, but I feel that there is a missunderstanding on my or on your side and I’m trying to clarify.
Using a branch based on the main branch(a feature branch) is a common practice. If the branch has no relation to the main branch why would it be in the same project?
What do you mean by more reliable? The cache will never have any impact on the content of analysis results and its reliability. Analyzing the same code, with any type of cache even if it is from a different project will lead to the same result.