We use CI integration from Azure DevOps to SonarCloud, with MSBuild Project. Mainly analysing C# and JavaScript files.
Our problem is we have many thousands of long standing legacy code smells and other Sonar Cloud issues and this creates a huge number of Sonar Comments in any touched file in our PRs which drown out issues relating to actual lines of code changed in the current PR. This causes developers to disregard all Sonar Comments because of the noise, even on their own code.
Is their a way to switch of PR annotations of issues that are not related to the active code changes in the PR?
I have a workaround which is to mark the legacy issues as resolved, not being done, but that seems wrong as we do expect to revisit the old code at some point and so do not want to hide these old issues. In this example one code change in the file led to a few hundred legacy issues being added to the PR comments.
hi Colin - yes we have the main branch run every night. This shows all the 25K ‘legacy’ issues which we would like to be able to turn off in such a way that they do not get reported into the PR comments - there we only want to see comments relating to changes made by the PR author.
We do not mind if the issues are still visible in SonarCloud for the PR. The main problem is the proliferation of Comments in the PR.
We do mind, as we really think that pull requests should only focus on changed code.
Do you see any WARN messages in your analysis logs when analysis is run on a PR? Such as a shallow clone being performed, not being able to detect changed files/changed lines…
Well I do agree (I have signed up for the Clean Code Webinar!) …
I have worked quite hard to make sure all the warnings are cleared, so using latest Node/npm and we have the full git clone, so no warnings about Shallow clone. We can see the full change history in Sonar which shows the originator of the issue and how it got merged through to current PR.
Here is a test change I made to two lines, in a PR 12th May, and as well as my changes, Sonar has reported warnings made by other originators on other lines which were not changed in this PR:
The strange thing is if I drill into the activity on one of these old issues the issue is shown as issue created on 12th May by the original author, but that is definitely wrong because this is my own branch and no one would be making changes other than me. It seems this is misconstructed somehow. (Ignore my changes to the resolution as this was done afterwards).
Something is funny here. I’ll flag this for an internal team to investigate. In the meantime, it would be great if you could prepare DEBUG analysis logs of a PR that behaves like this (the sonar.verbose=true analysis parameter should do the trick). Whoever takes a look at this thread can open a private message to receive them.
I think I may be on to something … the nightly run on master was not correctly pulling the full git repo for master (for disk space reasons we had limited it) so the change history was not fully annotated (blame). I have now managed to get a full run on master and rerun the PR and I think it is now doing what it should - only showing code changes.
I am doing a new PR and new run, with debug, to check it from scratch.
Further to my last message I can confirm that having run a complete scan on master with full depth git clone, and then a PR with a similar full depth git clone, the Sonar analysis is now correctly reporting only the changed lines of code and correctly attributing them to the PR owner.
Many thanks for your assistance and direction with this. It made me look in the direction where the problem lay.
Thanks a lot for the follow-up! Does that mean you have different pipelines set up for master compared to your PRs (with a different checkout strategy)? Just want to make sure I understand fully to help the next person who has the same issue.
It was a bit tricky to fix because the fixes I was making were in the YAML for the PR, so although I could run the Sonar pipeline in the PR, I could not run it in master as that would not have my changes yet (catch 22!)… so the master run was not correctly pulling the complete git version history. So I had to hack an old legacy ‘classic’ pipeline to run the full git fetch on master. This shows as the main ‘long lived’ branch in Sonar and once I saw we had the correct author annotations there I knew we were making progress (no more warnings about shallow copy). Having fixed master I could then run the PR that then showed the correct line change ownership.
Now the PR is merged into master, the same pipeline will run on master and on any PRs. The tricky bit is getting it to run on the full branch as well as on the incremental PR, because I was getting out of disk space and out of java memory issues, and the Sonar background tasks taking longer than 30 minutes. So plenty of hurdles to jump but Sonar is fantastic. I would only ask for more logging on the background Analysis tasks and the ability to give them more than 30 minutes as with a full branch on our code base that was timing out until it got a clean run and built its caches etc.
This is the script for the checkout which seems to give Sonar everything it needs (either in master branch or PR)
Now I just need to figure out adding typescript files to the analysis which are not in the msbuild project definitions and get code coverage… another day!
