Persistent cache for Pull Request Analysis for CFamily

From what I’ve gathered from this part of the documentation

The C/C++/Objective-C analyzer automatically caches the analysis results on the server. The cached analysis results speed up subsequent analyses by analyzing the only things that have changed between the two analyses.

  • 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.

and this post CFamily Analysis Cache Questions - #3 by Abbas

I’m gathering that SonarQube does not store a cache for each Pull Request, but will always use the cache from the base branch if I push further changes to the branch and thusly trigger another pull request analysis.

I think it would be valuable if there was a cache for each Pull Request, which would speed up the analysis when we make small changes to a pull request, when the pull request is already making big changes compared to the base branch. Given that SonarQube already stores a cache for branches if we perform branch analysis instead of pull request analysis, it would seem like it would be possible to do this also for pull requests. Put a different way, not providing this functionality for pull requests seems to act as a motivation for using branch analysis when pull request analysis would otherwise be more applicable.

Up until recently we’ve been using the old style filesystem cache through a separate cache server, which has honestly not been the best solution. I’ve put in the effort to resolve the deprecation warnings that suggest to let the SonarQube server handle this. Our previous solution would try to load the cache with a key based on the branch name, and no cache gets found, it would fall back to the cache from the main branch. Using the server side cache seems like a better solution, but losing this capability is a bit sour.

Hello @torgeir.skogen

Thanks for reaching out.

I will start with a quick clarification. The old-style cache is not deprecated. It is just the properties used to configure it that changed name.

One of the main reasons to keep the old-style cache is to leave more flexibility to our users so that they can implement optimal caching strategies for their workflows if needed.

That being said, what you describe here is a pretty typical workflow and supporting it could make sense.
It has not been done so far for a few reasons, including:

  • for many (most?) pull requests, using the base branch gives most of the speed-up and then most of the value
  • storing a cache for all PR branches could clutter the SQ database
  • C++ is just one of the languages analyzed on SonarQube and caching mechanisms are shared by languages

Your request makes sense and I record it.