We historically used the C++ caching feature to speed up our PRs. However we have today noticed that some files are being changed and still matching the cached file, which means they are not raising their new issues in our main scan.
This caused us to notice the deprecation warning for the old C++ cache settings, and wondered whether using those could be causing this to happen?
Also, as part of caching manually we had to move the code in our CI system to use the exact same path every time. e.g. in our CI, the code is checked out to C:\build\x\s.âŚ, where âxâ could be any number. This caused the cache files not to be hit, so we have steps in the CI build to copy the code over to C:\static-build-directory on checkout. If we migrate to the new server caching, is this still a requirement?
Also, as part of caching manually we had to move the code in our CI system to use the exact same path every time
The cache can work with relocation to an extent. For instance, if you were to define a macro with the compilation path, then the compilation wouldnât be the same.
Anyway, to better help you, can you please share
which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
The analysis log in debug mode (sonar-scanner -X)
I can send you a private message so you can share the logs privately.
@aalvarez thanks, I have sent over the logs as requested along with a specific file thats hitting this issue so you can see it. Let me know if you need any more info as I am keen to understand why these files are hitting the cache when they have changed
We have followed the discussion in private, looking at the logs and at SonarQube.
Finally, @jlawless found that the issues did not really disappear: they are considered âoldâ issues on the main branch, even though the lines where they are located are highlighted as new code.
In summary, the problem looks like the following:
A PR is open against the main branch. A set of old issues are seen as new in SonarQube (i.e. they show as introduced 5 days ago).
The PR is merged. The analysis runs as expected. The CFamily analyzer sees the issues, but they are treated by SonarQube as introduced between 1 to 2 years ago.
They are not visible under âNew Codeâ, so it seems like they disappear. In fact, they are under âOverall Codeâ because they are not new. The lines are, however, highlighted as new code.
From my side, it looks like the CFamily analyzer is not related to this issue. I reassign to the SonarQube team, they will know better what is happening.
Sorry for the late reply. Can I ask you which version of SonarQube youâre running? And can I ask you to send us the scanner logs (redacted plain text, preferably), ideally when analyzing a PR that exhibits this odd behavior, and when analyzing the main branch after merging? You can run your analysis with the -X flag to run in debug mode, which will give us more logs.