I am trying to enable analysis cache for a project containing cpp files. The cache is successfully generated during the buildprocess. However, on consecutive builds the previously generated cache will not be re-used resulting in the following error:
DEBUG: Cache miss for C:\<path-to-file>\file.cpp: response file not found, request changed
...
INFO: Cache: 0/9 hits, 2084928 bytes
What concerns me here is the message: “response file not found, request changed”
I could not find any hints online towards what this message might suggest and to me its intention is somehow cryptic…
Question: Has anyone encountered this error message before and could give me advice on what might be going wrong here?
Detailed description:
The build is done through a Jenkins Multi-configuration project (via Matrix Plugin) and each configuration has a seperate folder for analyis cache assigned to it. The cache for each configuration is stored on a central location on the buildserver and copied in/out of the workspace for each build-configuration prior/after the analysis.
The workspace is cleared between builds but the absolute path to each source file stays constant for consecutive builds, so this should not be the reason the cache gets invalidated.
When building the same project on a local machine, all of the analysis cache gets successfully re-used. I am currently investigating whether the small changes inside the Build Wrapper output between consecutive builds might invalidate the cache (some environment variables get adjusted due to incrementing the buildnumber).
this seems to be relevant information. For instance, if you had the build number as a macro definition, that would lead to a cache miss with the message you mentioned. It would be a cache miss because the compilation unit build configuration is different from the previous run.
Thank you for that insightful hint @mpaladin. I can indeed confirm that a macro definition is the reason for the caches not being re-used.
Viewing the Build Wrapper output for two consecutive builds (build number 1034 & 1035) side by side reveals that there is a macro definition “VERSION” that will increment on each build:
This macro definition is present for each compilation unit and therefore changes the build configurations on all files of the project. Unfortunately the configuration can not be easily set individually for each file and most of the files do not rely on this macro definition.
I am unsure what workaround would be reasonable for this situation:
Is there some functionality for SonarScanner that allows to ignore specific macro definitions?
Should the build version better be written into a separate header file during some pre-build step to get rid of the macro definition inside the build configuration?
Or maybe there is a more obvious workaround to this issue that I do overlook here?
there is no functionality to ignore specific macro definitions.
One option is to replace -DVERSION=\"[0-9]+.[0-9]+.[0-9]+.[0-9]+\" with something stable like -DVERSION=\"1.2.3.4\" in the build-wrapper-dump.json after the build and before the analysis, you could use sed for instance.
I implemented this suggestion and let it run on the buildjob for the past few days. So far everything seems to work as expected. I am getting 100% cache hits on builds without changes in source files. Another advantage of keeping the macro definition constant for analysis is that even source files relying on this macro are able to be cached. So thank you for the suggestion!
