Hello, we are using SonarQube 9.6 developer’s edition. We had a commented code smell on code which was fixed but someone by mistake reopened that issue then closed it. But Sonarqube still keeps showing that commented code issue even thought that part of the code doesnt exist on repo. When I go to code on SonarQube somehow that comment is still present which is not present anymore in source code. Can someone please explain what is happening here and how to fix this?
Hi,
Could you provide a screenshot (redacted as necessary) of the issue in question? Particularly, I’d like to see its changelog. E.G.:
Ann
Hello Ann,
Thanks for the reply. Please find the images attached.
As you can see from the images it was fixed on October 12th, but it keeps getting reopened. And the part of code for which it shows the issue is not present anymore on actual repo, so we are not sure how to remove it or avoid this kind of scenario in future. Any help or explanation would be great.
Hi,
Thanks for the screenshot!
Just to make sure:
- Does this issue have secondary locations, or just the main location?
- When you look at the blame data on the issue location(s) (you can find it by clicking in the margin in SonarQube)
what’s the most recent change date?
Ann
Hi,
I am not sure what you mean by secondary location since we only have main branch and pull request analysis. We do not perform any other branch analysis. Also the date for the last revision is 27th Sep.
1 Like
Hi,
Thanks. This screenshot is what I was looking for. I’m going to ping the team about this.
To answer your question, sometimes SonarQube highlights locations that contribute to an issue, such as this:
Ann
Hi,
Ok, since this issue is regarding a commented line of code it’s connected to a single line of code only. So I don’t think there’s any secondary location.
1 Like
Hi,
About the “Resolved as fixed” status. Developers will use it to go through the list of issues they are fixing. But if the issue is still present in the code during the next analysis it will be reopened.
As you can see in the documentation:
- Resolve - If you think you’ve fixed an open issue, you can Resolve it. If you’re right, the next analysis will move it to closed status. If you’re wrong, its status will go to re-opened.
You might want to use “Resolve as won’t fix” if you decide to keep the line of code to be commented but don’t want the issue to be open.
Hope this helps,
Antoine
Hi, it’s not that we dont want to fix it but its already fixed(removed the commented code) but it still shows as issue on Sonarqube.
Hi,
Have you reanalyzed since the commented code was removed?
Ann
Hi, we have multiple PR’s getting merged into our main branch everyday which always triggers a new scan so yeah it should be getting scanned.
Hi,
So the commented code is gone from your main branch, but it - and the issue on it - still show up in SonarQube? Sounds like a problem with what’s being checked out.
Ann
Yes thats what is happening. And I am not sure whats going wrong.
Hi,
I’d say the wrong version of the code is being analyzed. You need to debug your checkout.
HTH,
Ann
Hello, I just went and checked the files checked out on local files where it was checked out for build in our build agent and it looks fine there. Please look at following images:
Is that what you were talking about or is it something else?
Hi,
SonarQube doesn’t cache old versions of source code. What you’re seeing in SonarQube is what you fed into the most recent analysis. You need to look at what’s being analyzed.
Ann